[1007] in Moira
Re: afs.incr question
daemon@ATHENA.MIT.EDU (Richard Basch)
Thu Aug 22 18:44:11 1996
Date: Thu, 22 Aug 1996 18:43:01 -0400
To: danw@MIT.EDU (Dan Winship)
Cc: moiradev@MIT.EDU
In-Reply-To: <199608222146.RAA08958@technomage.MIT.EDU>
From: "Richard Basch" <basch@lehman.com>
Since I am the author of that code, let me explain...
An AFS volume owner has implicit "administer" rights on the volume, and
is completely determined by the uid of the root directory of the volume.
The user id that is associated with the root directory of the volume is
should be the "owner/owners" id as listed in the AFS protection
database. Negative id's represent groups, while positive id's represent
users, as defined in AFS. For activity and project volumes, it was seen
that the group that administers the volume will likely stay the same,
but the group's constituency might change over time, so you do not want
to have a single user with implicit administration access.
Therefore, I had the project/group type lockers have the group (a
negative value) be the uid that was associated with the volume root,
and a user id (positive value) be associated with an individual's
volumes (homedir, urop).
If Solaris does not support these semantics, yell at Sun, as this type
of restriction should not have been enforced in the VFS layer; it should
have been enforced by the underlying FS layer after the VFS dispatch.
It is definitely a bug! Also, changing the semantics is not an option,
because of its intended purpose (and I know of several groups at MIT
where the original members have left, and they would be the only ones
who would have the rights to change the lockers... and also those uid's
tend to get reused, giving other new freshman implicit "a" access to
other groups' volumes). Unfortunately, there is no AFS pioctl that
accomplishes the same thing (I knew this to be a problem with some
platforms even when I was there, and wish I had implemented one, but I
was trying to keep the AFS changes down to a manageable set).
I hope this answers the question, and if you have any further questions
regarding this, feel free to ask.
-Richard
On Thu, 22-August-1996, "Dan Winship" wrote to "moiradev@MIT.EDU" saying:
> afs_create.pl has this bit of code:
>
> if ($type =~ /ACTIVITY|APROJ|PROJECT/) {
> chown($gid,0,$path) ||
> die "Unable to set volume ownership\n";
> } elsif ($type =~ /HOMEDIR|UROP/) {
> chown($uid,0,$path) ||
> die "Unable to set volume ownership\n";
> }
>
> where $gid is a negative number. But, chown apparently doesn't allow
> negative uids under Solaris. (chown(2) returns EINVAL in that case).
>
> So, the oracle server won't be able to set the owner of a locker the
> same way the current server does. Can anyone see a way around this? Is
> this a problem? Is there some reason to not do chown($uid, $gid,
> $path) in all cases instead?
>
> -- Dan
--
Richard Basch
Sr. Developer/Analyst, DSO URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 38th Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
