On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust <[email protected]> wrote: > > On Mar 31, 2014, at 7:51, Jeff Layton <[email protected]> wrote: > >> On Sun, 30 Mar 2014 09:03:29 -0400 >> "Theodore Ts'o" <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
