From mboxrd@z Thu Jan  1 00:00:00 1970
From: Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca>
Message-Id: <200306301817.OAA27322@plg2.math.uwaterloo.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] book chapters
Date: Mon, 30 Jun 2003 14:17:44 -0400
Topicbox-Message-UUID: e1eaef56-eacb-11e9-9e20-41e7f4b1d025

> From: Jack Johnson <fragment@nas.com>
>
> Where I have problems with matt's solution breaking down is when you
> have worker_5 creating random sets of files in a traditional hierarchy.
>   Any subfolders he/she/it creates lose the rw permissions for the
> bosses group, and even with the sticky bit set for the group you lose
> those permissions the next level deep.

Directories created in a group-sticky directory are group-sticky, at
least on the UNIX-esque systems that I use.

> The specific example I see at work is where you have (young) students
> who want or need direct assistance or supervision from their teachers,
> but the teachers don't want to make it drag-and-drop easy for the
> students to submit another's work as their own.  This often is as simple
> as helping a student locate the correct version of a document or
> assessing student work in-place without going through some sort of data
> or paper submission process.

We do exactly that here at Waterloo, using standard groups.  Every
student in CS 452 (for instance) has a cs452 directory owned by group
cs452; only the course staff are members of this group.  This works
well for things like e-mail help.  For the upper-year courses where
cheating is less of an issue, we can get students to submit simply by
throwing their stuff in this dir for us to peruse at our leisure.

A cron job sweeps the file system each night to fix the permissions on
class dirs for the benefit of those who delete or break things.

> Typical scenario:
> -> Disallow students to share/see each other's work
>    -> Allow staff to see work but not modify/delete
>      -> Allow administrators to read/modify/delete

This is almost what we get, although staff have modify/delete access.
If you don't trust your staff with student work I think you have bigger
problems than just your file system.

We have solutions for your other scenarios too, although I'm sure
they'd be much prettier with ACLs.

> Even in an ACL world things aren't perfect, but it does seem to allow
> one the flexibility of trying to accomodate the real world rather than
> attempting to manipulate human behavior to accomodate a file creation mask.

Although the flexibility generally comes at the price of increased
complexity.  Then again, human behavior is inherently complex, so it
might be an appropriate trade-off.

I don't really mean to come out against ACLs -- they're a good thing if
they allow users to create "groups" for themselves without
administrative intervention.  But if there existed a simple mechanism
to allow users to define and manage their own groups, I'd probably
never want them.

- Richard