On Wednesday, April 04, 2007 08:33:34 PM +0100 David Howells
<[EMAIL PROTECTED]> wrote:
That'd be my bet too. I suspect that the PAM module (if that's what it
is) that issued setpag occurs before the pam_keyinit PAM module also.
Oh, hm. That's not good. We may find ourselves back in exactly the same
situation that made it necessary to trap setgroups in the first place - it
doesn't work to track PAG's using something whose inheritance semantics are
different from those of PAG's.
If this is the case, I would suggest not applying keyring quotas to UID
0; if root wants to exhaust all the resources the machine has to offer,
so be it.
That's not a good solution. The afs_pag gets attached to the root user's
default session keyring, displacing any afs_pag that was previously there.
It shouldn't get attached to the default session keyring at all, because
that would cause the PAG to be inherited by newly-created sessions for that
UID, wouldn't it? That's certainly not the right thing; a PAG should be
part of the session's actual keyring (with one being instantiated, if
necessary), not the user's default session keyring.
What does the setpag code look like?
See <http://cvs.openafs.org/src/afs/LINUX/osi_groups.c>, particularly
setpag().
-- Jeff
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
