Bill Stivers <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] SysAdmin
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
