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? <<CDC _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
