[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <336243.38765.qm@web36610.mail.mud.yahoo.com>
Date: Tue, 18 Sep 2007 10:58:43 -0700 (PDT)
From: Casey Schaufler <casey@...aufler-ca.com>
To: Trond Myklebust <trond.myklebust@....uio.no>,
David Howells <dhowells@...hat.com>
Cc: viro@....linux.org.uk, hch@...radead.org,
linux-kernel@...r.kernel.org
Subject: Re: Credentials test patch
--- Trond Myklebust <trond.myklebust@....uio.no> wrote:
> On Tue, 2007-09-18 at 17:33 +0100, David Howells wrote:
> > Hi Al, Christoph,
> >
> > Here's a new version of my credentials patch. It's still very basic, with
> > only Ext3, (V)FAT, NFS, AFS, SELinux and keyrings compiled in on an x86_64
> > arch kernel. The patched kernel compiles, links and runs.
> >
> > I've made the following major changes to the patch:
> >
> > (1) System calls that might want to use the credentials call
> > update_current_cred() before calling into the VFS or whatever. This
> > allows the keyring pointers in the cred struct to be updated.
> >
> > (2) I've got rid of current_cred(), __current_cred() and the accessors for
> > current's fsuid, fsgid and group list. Instead you just use
> > current->cred->whatever. You don't need RCU to read the current
> threads
> > credentials as only you are permitted to change them.
> >
> > David
> > ---
>
> What about the process' capabilities? Shouldn't they also be part of a
> credential?
As should the LSM security blob, if appropriate.
What I don't really understand is what value is gained by this exercise.
Are the savings sufficiently significant to justify the effort?
Casey Schaufler
casey@...aufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists