[709] in Info-AFS_Redistribution
Re: pts: ID 0 and groups of groups
daemon@ATHENA.MIT.EDU (Peter Lister, Cranfield Computer C)
Thu Apr 9 06:59:59 1992
To: info-afs@transarc.com
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, dl2n+@andrew.cmu.edu
Date: Thu, 09 Apr 92 10:41:10 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
A couple of comments prompted by answers to my query
First root != admin; I don't actually want to have admin with UID 0 because Unix
system admin is a different issue to AFS cell admin. OK, there's no security
advantage in separating the two, but at least a typo under UID 0 to update
system files won't wipe the entire cell (a risk with an admin token). It seems
that there is no fundamental problem (chown root works, after all), but AFS code
assumes that UID 0 can't exist. Is this different in OSF DCE?
Second, hierarchy != recursion. Yes, recursive groups with arbitrary membership
would be a nightmare. So the obvious solution is - disallow recursion. All
that's needed to generate an acyclic tree is a level counter associated with
each group. Users would be level 0, groups of users level 1, and so on, and
groups could only contain members of a lower level.
Finally, I'm not sure what Dan Lovinger means by
> In practice, we've never needed them. Making clearly defined groups for a
> specific purpose suffices. You don't have random groups - you have a
> sysmaint:motif.commanders, sysmaint:x11r4.commanders, sysmaint:corps ... and
> so on.
A "clearly defined group" is exactly what I want. We should be able to define
AFS access control in terms of the structure of the institution, i.e in terms of
a user's membership of classes, groups, etc, and then a group's membership of a
school, the timetable or whatever. Trying to update EITHER all ACLs that refer
to a particular group OR all users who fall into the union of half a dozen
groups in infeasible. AFS allows us to do great things; a relatively small
change would allow much more. I include an example below.
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
------------------------------------------------------------------------
PS - an example. A package is licensed to concurrent use on any 25 of 90
workstations. Access is unrestricted unless a tutor has scheduled a class using
the package, because he needs to restrict access to the group(s) attending the
class and a small group of priority users. At the moment we must EITHER change
all the relevant ACLs to include only these groups during the class, or we must
regenerate membership of a package:users group using a script.
What we should be able to do is set ACLs for package1:users ONLY, and do the
rest with pts. Before the class:
pts addmember -group package1:user -member student:group1 student:group2 \
project:group3
pts removemember -group package1:user -member system:anyuser
After the class:
pts addmember -group package1:users -member system:anyuser
group1 group2 and group3 are groups maintained by or on behalf of another
department, or student registry. They are almost certainly NOT maintained by the
package support staff.
------------------------------------------------------------------------
