On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust
<trond.mykleb...@primarydata.com> wrote:
>
> On Mar 31, 2014, at 7:51, Jeff Layton <jlay...@redhat.com> wrote:
>
>> On Sun, 30 Mar 2014 09:03:29 -0400
>> "Theodore Ts'o" <ty...@mit.edu> wrote:
>>
>>> On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
>>>> I had some time to think about this last night...
>>>>
>>>> While using a fd to pass around credentials is convenient, the danger
>>>> is that it's pretty opaque. You have a fd that you know has creds
>>>> attached to it, but it's hard to be certain what is going to change.
>>>
>>> I don't think that's a particularly tough problem.  In general, the fd
>>> isn't something that you would want to pass around, and so the process
>>> which generated it will know exactly what it contained.
>>>
>>
>> I think there's a bit more of a use-case for passing around such an fd
>> via socket...
>>
>> Part of the problem is that the traditional uid/gid switching glibc
>> wrappers are per-process. If we're proposing doing something like:
>>
>> seteuid()
>> setegid()
>> setgroups()
>> fd = open()
>> (...and then revert the creds using same syscalls)
>>
>> ...during the time that you're doing all of that, you can't really
>> allow any thread in the process to be doing something that requires
>> _other_ creds until you've completed the above.
>
> Umm... open() isn't the only operation that you want to be able to do with an 
> assumed user identity. You want mknod(), mkdir(), link(), unlink(), ... 
> Pretty much any interaction with the underlying filesystem needs to use the 
> right identity.
>
>> So, I could envision a program like ganesha firing up a separate
>> process to handle the credential switching and fd creation and then
>> handing those back to the main process via a unix domain socket.
>
> How about using the keyrings interface to atomically cache and retrieve these 
> user identities? We already have support for different types of keys that 
> store/retrieve different types of structured information. How is this so 
> different?

This sounds considerably more complicated than just using fds.  What's
the advantage?

I guess using keys for local fs credentials fits in with using keys to
access things like AFS, but I'm still not sure I see why this helps
here.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to