[704] in Info-AFS_Redistribution
Re: pts: ID 0 and groups of groups
daemon@ATHENA.MIT.EDU (Daniel Edward Lovinger)
Wed Apr 8 14:08:10 1992
Date: Wed, 8 Apr 1992 13:18:18 -0400 (EDT)
From: Daniel Edward Lovinger <dl2n+@andrew.cmu.edu>
To: Info-AFS@transarc.com
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
In-Reply-To: <9204081542.AA26358@xdm001>
"Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk> writes:
> I would like to be able to create an AFS user root with ID 0 so that I when I
> tweak system files within AFS, I don't have to explicitly chown root all the
> time (even if I su root, new files are still owned by the AFS ID I use).
>
> pts cu root -id 0 ignores the -id and uses the next highest ID. Is this special
> handling of ID 0 prejudice by pts or an integral part of AFS?
To a certain extent: orphaned groups (w/o owner) are owned by
id 0. I'm not aware of another magical meaning.
> Also, how can I make groups members of other groups? I can't get this
> to work! I had assumed that this obvious and desirable feature would be
> available. Could I be wrong? If so, will Transarc please rectify this
> omission; we need to be able
> to grant multiple groups access to multiple files without having to explicitly
> add users to a special group, or explicitly add groups to each ACL. If
> there is a reason for the omission (other than oversight), is it
> fundamental to AFS, or just pts prejudice?
This is fundamental. The most concise reason I've heard is
that adding recursive groups would require loop checks which take
potentially indefinite time and space in a server process which
*cannot* be slow (we've found other ways to make it slow - believe me,
a pokey ptserver is a Bad Thing). 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. Groups like
sysmaint:corps (presumeably the list of people in the support
organization) only has limited explicit access. Its members on the
other hand may belong to potentially a lot of project by project
groups.
It doesn't sound like you are aware that ACLs exist on the
directory level, not the file level. This, IMHO of course, greatly
simplifies things and I am not sure I like the fact that DFS is going
to have to have file-by-file ACLs ...
Dan Lovinger Computing & Communications Carnegie Mellon U.
Internet: dl2n+@andrew.cmu.edu Bitnet: dl2n+%andrew.cmu.edu@carnegie
"... and in the stillness, they heard the cry of the golden banana ..."
