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
[EMAIL PROTECTED]
v) 831-459-2472
f) 831-459-2914
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
