[713] in Info-AFS_Redistribution
Re: groups of groups
daemon@ATHENA.MIT.EDU (Peter Lister, Cranfield Computer C)
Fri Apr 10 07:06:08 1992
To: Lyle_Seaman@transarc.com
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, Info-AFS@transarc.com
In-Reply-To: Your message of Thu, 09 Apr 92 09:54:24 -0400.
Date: Fri, 10 Apr 92 10:20:42 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
May I quote p6-1 para 3 of the AFS 3.1 Command reference manual.
"Groups make it possible to add someone to many ACLs by adding them to
a group that already exists on those ACLs (and it is just as easy to
remove someone the same way)."
NOWHERE in the AFS manuals can I find reference to the fact that group
membership is cached only at authentication, and remains for the
(potentially infinite) lifetime of his ticket. If I thought about this
at all, I assumed that pts info would be obtained as needed for
particular ACLs, have a limited lifetime. It's arguable that if a user
who is denied read information after the first read has already read
it, but pts info MUST be updated when flushing cached writes back to the server.
I don't care what Transarc staff say about slowing pts it MUST BE
SORTED OUT. Caching group info is a security loophole. So is the lack
of group hierarchy, as it forces system administrators to use groups
and ACLs in ways make access control info become out of date. (groups
because of caching, ACLs because it's impossible to keep track of them
all). There should, at the very least be a prominent health warning in
the system manager's documentation.
Peter Lister p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology, Voice: +44 234 750111 ext 3157
Cranfield, Bedfordshire MK43 0AL England Fax: +44 234 750875
