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" <sangelov...@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.
