Messages in this thread | | | Date | Thu, 20 Sep 2007 08:36:57 -0700 (PDT) | From | Casey Schaufler <> | Subject | Re: [PATCH 3/3] CRED: Move the effective capabilities into the cred struct |
| |
--- Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> On Wed, 2007-09-19 at 21:11 -0700, Andrew Morgan wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > David Howells wrote: > > > Move the effective capabilities mask from the task struct into the > credentials > > > record. > > > > > > Note that the effective capabilities mask in the cred struct shadows that > in > > > the task_struct because a thread can have its capabilities masks changed > by > > > another thread. The shadowing is performed by update_current_cred() > which is > > > invoked on entry to any system call that might need it. > > > > OOC If we were to simply drop support for one process changing the > > capabilities of another, would we need this patch? > > No. This has nothing to do about one process changing some other > process' capabilities. It has to do with being able to pass security > information around the kernel beyond the confines of the task struct. > > This is needed in order to deal with asynchronous i/o where security > checks may have to be deferred, and where the task struct may no longer > be available. > One example would be a failover situation when doing deferred writes: if > the first choice of storage medium is unavailable, and the kernel tries > to fail the write over to another storage. On NFS that might involve > having to build up a new RPCSEC_GSS security context for the new server. > Currently, you cannot do this safely because all the security info is > cached in the task struct and much of it cannot be copied.
Ok, what can't be copied, and why can't it be copied?
Casey Schaufler casey@schaufler-ca.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |