[OpenAFS] Re: fs setacl and permissions
Jeffrey Hutzelman
jhutz@cmu.edu
Wed, 31 Jan 2007 14:55:59 -0500
On Sunday, January 28, 2007 01:10:11 AM +0200 Juha J=E4ykk=E4 =
<juolja@utu.fi>=20
wrote:
>> So what it really comes down to is this: I claim that, if someone who
>> "owns" a directory (i.e. has "explicit" a privs) defines a subdirectory
>> and restricts someone else to non-a privs there, it is really a
>> security breach for that someone else to be able to get "a" privs
>> anywhere below it. But that's exactly what this "implicit a privs for
>> a directory's owner" provides.
>
> Good point, but one question immediately arises: why was the other
> obvious solution discarded? The other one being as follows. Suppose your
> scenario with a teacher, who owns and has "a" at dir1 plus a bunch of
> students, who own dir1/student1, dir1/student2 etc and have "a" in their
> respective directories. Suppose teacher also wants to have "a" on all
> subdirectories of dir1. Now, your problem can be solved by allowing
> anyone with "a" access to dir1 to alter the ACLs on all its subdirs. This
> way, if a student removes the teacher from the ACL of dir1/student1, the
> teacher can always grant oneself the access again. I fail to see which
> security holes this would open, although I wouldn't be surprised if it
> does since the regular unix filesystems and chmod/chown do not seem to
> allow this either.
You can do that, if 'dir1' is a volume roor and all of the student=20
directories are part of the same volume. A better solution is to create a=20
separate volume for each student directory, and make all of those volumes=20
be owned by the instructor instead of the students.
The behavior you're asking for, "if I have 'a' on a directory I should be=20
able to change the ACL of anything below it", is actually very hard to=20
implement. This is because directories are not containers; they are tables =
which map filenames to vnode numbers. So, a file or subdirectory isn't=20
actually _in_ a directory; it's just referred to by it. The sort of check=20
you want to do would require the fileserver to walk up the tree looking at=20
the access rights on each directory above, and that's just not possible.
What we do provide is that the owner of a volume gets implicit rights on=20
_every_ object in that volume, regardless of the ACL. This is consistent=20
both with the fileserver architecture and with the model that volumes=20
represent the smallest unit of storage for administrative purposes.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA