From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3F006BC5.4070309@nas.com> From: Jack Johnson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030416 Thunderbird/0.1a MIME-Version: 1.0 To: 9fans@cse.psu.edu Subject: Re: [9fans] book chapters References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 30 Jun 2003 09:56:37 -0700 Topicbox-Message-UUID: e1bd3430-eacb-11e9-9e20-41e7f4b1d025 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