Re: problems with changing UID/GID

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Dave McCracken <dmccr@us.ibm.com> writes:

     > Shouldn't the Linux cred structure include the capabilities, as
     > well?  What about places that want to see both uid and euid?
     > Shouldn't euid/egid also be in the structure?  I realize that
     > for file operations they're not strictly necessary, but we
     > should make the structure useful across all parts of the kernel
     > that want to see credentials.

The BSD approach is to split out the user credentials, since they are
used all over the place in the filesystems, and often need to be
cached. The uid, euid, ... are kept in a reference-counted 'process'
credential of the form

struct pcred {
       struct ucred *ucred;
       uid_t uid, euid, suid;
       gid_t gid, egid, sgid;
       int count;
};

In Linux, we should probably also include the capabilities as part of
the pcred. They sort of fall outside the BSD model, so it's hard to
tell exactly where they belong...
That said, I'm motivated to move away from thinking that they belong
in the ucred, by the fact that capabilities contain information about
whether or not you are allowed to change those user credentials. That
just doesn't fit with the idea of copy on write.

     > BTW, you've convinced me that your approach is the right way to
     > go.  I'll make another stab at CLONE_CRED after the VFS changes
     > are made, which will make it a 2.7 item, I'm sure.

Great. As I said, I've resumed working on the ucred stuff. Expect the
first patches to be announced for 2.5.x soon. The first few patches
are ready, I just need to test them with a post-2.5.32 kernel (as soon
as I find one that will actually boot on my laptop even without the
patches applied).

Note: If you'd like to take a peek at what I've got (and help me with
some feedback), see the directory

  http://www.fys.uio.no/~trondmy/src/2.5.32-alpha

Cheers,
  Trond