On Tue, 30 Jan 2007, Christopher D. Clausen wrote:
Bob Cook <[EMAIL PROTECTED]> wrote:
On Sun, 28 Jan 2007, Juha [UTF-8] JC$ykkC$ 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.
I'm not an expert on this stuff, but two things occur to me. One is
that your "obvious solution" doesn't allow me a different scenario.
Suppose I want to allocate a subdirectory to someone else and turn
over ALL control
to that person; i.e., I don't want to be involved any more; I don't
want to have ANY privileges in the new directory. With my scenario,
I can easily remove myself after adding rlidwka for the new "owner".
But with yours, I can't.
The other is that your solution doesn't allow me to allocate a
subdirectory to someone or group with permissions more restricted
than rlidwk, because the person/group can regain all those
permissions in the subdirectories they create, and I can't prevent it.
I see a need for both solutions. Would it be possible to change the
behaviour on a per-fileserver basis? That you could allow one scenario
on volumes on fileserver a and allow the other on fileserver b.
Perhaps a flag to the fileserver on start-up to select which method the
cell admin would like?
the problem is the right way is per-volume, but per-fileserver is probably
the best we can do today. anyone want to code it? (i can code it, it's
like 5 minutes work, but testing is a little more)
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
