Re: [9fans] book chapters

[Jack Johnson <fragment@nas.com>]

ron minnich wrote:
> On Mon, 30 Jun 2003, matt wrote:
>>>For instance, you have a set of people whose files you want readable by
>>>their supervisors, but not by their peers.
>>maybe I'm missing something
>>-rw-rw----  1 worker_5  bosses  851968 Jun  3 17:11 daily.toil
> From my point of view this is not the same.
> Jack wants "anybody but my boss"

Nope, matt got it right, I'm just an idiot.

Actually, you both got it right, I just used two conflicting (and
probably unclear) examples.

"Everybody but Bob" where Bob is my boss (as opposed to my uncle), is a
pain to continually manage, as you said, but matt's example is correct
where worker_5 is Nameless_Worker_In_Cubicle_5 and bosses is the
fluctuating innumerable set of people who have authority over his work.

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.

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.

Plus, without a super user per se in Plan 9, typical academic
institution style management slowly becomes increasingly complex:

(not to mention any Napsterized copyright infringements permanently
fossilized, or the variations in philosophy in the sharing of knowledge
vs. the stewardship of academic product :)

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

Shared project space:
-> Allow staff/administrators to create folders
   -> Allow any to read/create/modify subfolders/files
     -> Allow owner or staff/administrators to read/modify/delete files

Project/assignment submission folders:
-> Allow students to write data but not read
   -> Disallow students to delete/overwrite previously written data
     -> Allow staff/administrators to read/delete files

...plus the lovely subsets of complex human interaction:

	- Jimmy and Sally are working on a project, Sally can't delete
	  Jimmy's file but can modify it, so she deletes its contents.

	- Billy wants to copy Wendy's work, but can't just take it.
	  She drops it in the shared filespace of another class for him
	  to retrieve.

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.

I realize Plan 9 wasn't necessarily designed for this environment (and
I'm not currently using it as such), but looking at the file permissions
model in general it's interesting to ponder what a good, alternative
model could be.

I was idly watching the first eight minutes of "Revolution OS" at
ifilm.com a while back

	http://www.ifilm.com/filmdetail?ifilmid=2419320

and chuckling at some comment (probably RMS) talking about using blank
passwords and password crackers in the early days to underline the idea
that security was sort of a misnomer, it's better to share, blah blah
blah, but it made me at least reconsider the whole notion of file
security.  I've always thought it was better to attempt to secure the
service, host or protocol rather than (increasingly common it seems)
relying on a secure network (using firewalls, VPN and IDS) to protect
your network, and now from that clip I sometimes think, OK, if you
assume your filespace is insecure, lousy or whatever, what can you do to
mitigate that?  Write-only like fossil, or some shared cryptographic
technique like SFS, maybe.  Private namespaces can go a long way to
making it kind of a non-issue depending on how you decide to handle the
shared filespace, but I think it's good to realize that there are a
dozen different, *decent* ways of looking at the problem.

-Jack