[OpenAFS] File ownership/permissions semantics

Christopher D. Clausen cclausen@acm.org
Tue, 31 Oct 2006 16:24:25 -0600


Bill Stivers <stiversb@ucsc.edu> wrote:
> 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.

Since this is run by a script anyway, could you setuid the script and 
have it kinit and obtain a keytab as some other user with the proper 
access and have this one trusted account create a file for each user and 
copies files over as needed?  (Or at a minimum, create proper directory 
ACLs and allow the student to copy their files directly.)

(I realize you would need one "trusted user" for each class and that 
might get out of hand.)

Alternately, could you have some automated process create the 
directories and ACL them appropriately ahead of time?  E.g. create a 
pre-handin script that prepares the handin environment.  It would only 
need to be run by TAs / instructors to prepare a hadin area for each 
particular assignment.  This assumes that you have a complete class 
roster at the time the assignment is issued.  This may or may not be 
true in your environment.

-----

Or, instead of a push hand-in system, you could have a pull hand-in 
system.  Have a script copy the data directly out of each students 
~id/classnum/assignnum directory at the time it is due.  The student 
would be responsible for ACLing it appropriately (allow handin script, 
but not other students,) or the script could run on some trusted machine 
with full privs to grab the files.

<<CDC
-- 
Christopher D. Clausen
ACM@UIUC SysAdmin