[OpenAFS] Re: fs setacl and permissions

[Derrick J Brashear]

On Tue, 30 Jan 2007, Christopher D. Clausen wrote:

> Bob Cook <bobcook@slac.stanford.edu> 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)