Subject: Re: Process credentials change
To: Jason Thorpe <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 07/10/2006 15:30:42
Content-Type: text/plain; charset=us-ascii
On Mon, Jul 10, 2006 at 02:01:13PM -0700, Jason Thorpe wrote:
> On Jul 10, 2006, at 1:39 PM, Bill Studenmund wrote:
> >My concerns are around what's going on if l->l_cred !=3D p->p_cred. =20
> >Since a
> >process is supposed to have one credential state, if we ever change
> >p_cred, we REALLY need all the l_creds to change at the same time. And
> >that means a global lock.
> Unless you consider that an LWP entering the kernel is like a =20
> "transaction", and that the credential state should remain constant =20
> from the beginning to the end of the "transaction". Do you agree?
I'm not sure about the cause&effect here. :-) I DO agree that we don't=20
want an lwp to change credentials in the middle of a systemcall. However a=
shared lock with upgrade to exclusive will also do that. :-)
> If so, then it makes PERFECT sense to set the LWP's creds upon kernel =20
> entry, and not change those creds unless the LWP is requesting a cred =20
> change. That way, a cred change by the proc while the LWP sleeps =20
> (disk I/O?) won't screw up whatever the LWP is (legitimately) trying =20
> to do with the creds it started out with.
I agree we don't want to screw up the LWP.
But doing the above has an impact on changing credentials. We will return=
success on changing credentials before we've realy finished the change.=20
Yes, we've put things in place so the NEXT system call will use the new=20
creds, we are still using the old ones. If the unchanged LWP stays in the=
kernel "for a while", then we have a measure of shadiness.
How do other OSs handle this? Do they care?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----