[OpenAFS] File ownership/permissions semantics

[Bill Stivers]

Thanks for the feedback.  I can understand the reasoning behind the  
different rationale;  our dependency is approximately as follows- if  
you or anyone else have any thoughts about duplicating the  
functionality we had previously inside the context of the new  
semantics it would be grand.  If we can't duplicate the semantics  
through some twisty permissions hack or some measure of group  
permissions twistiness, then we can always essentially switch to a  
drop-box like structure for homework, but if I can avoid that, I'd  
love to, because as a past CS student, it's nice to know when you've  
turned something in, that it's the right thing.

In essence, we have a homework submission system in which volumes are  
created by class.  Owners and TAs have full access and all  
privileges.  system:authuser has rli permissions.  In the past, our  
script would create a directory inside the homework submission  
directory by user.  Under the old semantic, the user who created it  
would have an implicit "a" privilege on their own directory.  The  
script would then remove the inherited system:authuser privilege from  
the directory that was student-created and grant full rlidwka  
privileges to the student account in their personal such that other  
students in the same class can't steal their homework, but via  
inheritance and explicit permissions setting, the student would be  
able to resubmit their assignment, check that they'd submitted the  
correct files, and keep full control over their assignment and its  
directory.  Upon the assignment coming due, the instructor or TA,  
with their omnipresent, all-powerful privileges would shut off  
student access to facilitate grading, either by manual or automatic  
means.

Presently, students can create their individual directories, but they  
only inherit parent permissions, they have no control over the  
directory that they create, which means they can't easily remove  
permissions for system:authuser, nor grant themselves permissions for  
directories which they create.  Under basic unix permission  
semantics, if I can create a directory or a file, I can manipulate  
that directory or file's permissions, even if I can't necessarily  
manipulate its parent directory's permissions, hence my confusion.

I can't see any way of implementing a similarly student-friendly and  
rational schema given the OpenAFS semantic.  It seems to me that I'd  
have to take away read permission from system:authuser, leaving  
system:authuser with list and insert permissions.  That would make  
things more drop-box like in an OS X/HFS semantics sort of sense, but  
that would seem to me to make it impossible to create any scenario,  
in which we could do this at all, because with list and insert  
privileges another malicious user could theoretically drop files into  
any given student's directory ahead of time preventing them from  
properly turning in their work.  While our scripts can search for  
this denial of service condition and let people know in advance, it's  
not an ideal solution- as a drop box, the given student can't really  
see what they've submitted to make sure that they've turned in the  
correct files.

Also:  In theory, we could have the TA or instructor run a workaround  
that explicitly removes rli or li permissions from subdirectories and  
explicitly grants full rlidwka access for those subdirectories by  
user, but that implies that instructors have time to do this, and  
that class lists are current, and that all other aspects of the  
experience are in perfect alignment in any given circumstance.

If it's possible to do this, and I'm an idiot, just a one liner of  
"read the faq", or "it's probably in 'n' manual" is fine.  If I'm  
correct in assuming that it can't be done without instructor or  
administrator intervention, and we'll have to dump "read"  
functionality for individual directory creators  to prevent  students  
from reading one another's assignments, an affirmative answer there  
would be great.

*continues tallying beer purchases to be made for future SAGE or  
other conferences* :)

Thanks for the continued insight and assistance.

--Bill


On Oct 30, 2006, at 4:12 PM, Derek Atkins wrote:

> It's a security hole to allow anyone with write access to gain
> administrative priviledges just through "mkdir".   In OpenAFS
> you still have implicit "a" access given to the owner of a volume
> (which is the owner of the root directory node of a volume).
>
> I do not believe there is a compilation flag to revert to the old,
> insecure transarc semantics.
>
> -derek
>

---
Bill Stivers
IC Unix Lab and Systems Administrator
University of California at Santa Cruz
stiversb@ucsc.edu
v) 831-459-2472
f) 831-459-2914