(update) Pipe transport for Windows

[Peace <pc...@yahoo.com>]

I've uploaded a patch adding Named and Anonymous Pipe transport for Windows.
https://issues.apache.org/jira/browse/THRIFT-1558

"This patch adds named & anonymous pipe transport for Windows. The new
classes do not affect *NIX builds. We've been using this code on Windows &
OSX for 6 months and I'm fairly confident in it. It has not been hammered
by automated tests and I welcome stress testing to wring out any bugs.

The TPipe and TPipeServer classes are generally modeled after TSocket and
TSocketServer. The server of course uses TPipeServer to set up the server
side then instantiates TPipe for communications. The client instantiates
TPipe transport for connection to the server.

Here are some code snippet examples from functions we've built. Variables
such as 'pipename' are passed in to the functions. Error handling has been
omitted."

...

I had hoped to make it cross-platform but since so much time has passed, I
figured someone might find it useful as is. It's Windows-only and excluded
on *NIX (sorry had to use #ifdefs). I put in some work on a separate branch
to support *NIX but don't have enough experience with ASIO to do it
justice. There may or may not be enough motivation to work on that since
domain sockets are already supported under *NIX and are a better option for
that platform.  Perhaps the pipe classes could become an abstraction that
implements Named Pipes under Windows and Domain Sockets under *NIX by
leveraging the existing socket classes.


Regards,
Peace

Re: thrift server questions

[Mark Slee <ms...@fb.com>]

This is fairly complicated and doesn't sound like a good use of the linux
file-permissioning system.

Thrift clients are not Linux users. Assuming you're using TCP (the common
case), they are data from an IP/port. You have no way of knowing which
user that corresponds to - you can encode it in the application message,
but that would be easily spoof-able and you'd definitely need a strong
security layer in place to feel confident changing your server's
capabilities based upon those messages.

This also implies you would be running your server as root, which is
generally not recommended.

I think it'd probably be better to use group-permissioning on the
filesystem, so the server can share file access with the right set of
users. You control file security by changing group membership and file
permissions, not with application logic in your server. Run your server as
a member of the relevant group, no sudo, no setuid/setgid, etc.

At a higher-level, what are you trying to accomplish here? Are your server
and clients sharing access to a filesystem? If the clients also have
access to the filesystem, why don't they operate directly on it?

Cheers,
Mark


On 4/26/12 3:52 PM, "Steve Angelovich" <SA...@lgc.com> wrote:

>I am building a server in java based on thrift.  The server needs to be
>able to interact with different users and to read and write files.
>
>The problem or question that I'm running into is how can I make sure
>these file based operation happen as the correct user?
>
>I'm currently starting my server using an xinetd script.  Would it make
>any sense to do a sudo to the same user as the client when starting the
>server if that is even possible?
>
>Is there a model or a best practice guide for linux when creating a
>service that needs to interact with multiple different users?
>
>Am I missing something?  Is this easy complicated or where do I start?
>I've looked for some ideas on the net but I'm not finding anything that
>looks promising.
>
>Thanks for any insights,
>Steve
>
>
>----------------------------------------------------------------------
>This e-mail, including any attached files, may contain confidential and
>privileged information for the sole use of the intended recipient.  Any
>review, use, distribution, or disclosure by others is strictly
>prohibited.  If you are not the intended recipient (or authorized to
>receive information for the intended recipient), please contact the
>sender by reply e-mail and delete all copies of this message.

thrift server questions

[Steve Angelovich <SA...@lgc.com>]

I am building a server in java based on thrift.  The server needs to be 
able to interact with different users and to read and write files.

The problem or question that I'm running into is how can I make sure 
these file based operation happen as the correct user?

I'm currently starting my server using an xinetd script.  Would it make 
any sense to do a sudo to the same user as the client when starting the 
server if that is even possible?

Is there a model or a best practice guide for linux when creating a 
service that needs to interact with multiple different users?

Am I missing something?  Is this easy complicated or where do I start?  
I've looked for some ideas on the net but I'm not finding anything that 
looks promising.

Thanks for any insights,
Steve


----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient.  Any review, use, distribution, or disclosure by others is strictly prohibited.  If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

support for intel compiler

[Steve Angelovich <SA...@lgc.com>]

I recently ran into a problem when compiling the some thrift generated c 
code using the intel compiler.

Are there any plans to fix this?

Everything compiled fine using gcc.


thanks,
Steve

----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient.  Any review, use, distribution, or disclosure by others is strictly prohibited.  If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.