[122] in DCNS Development

home help back first fref pref prev next nref lref last post

Re: Major problem with AFS

daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Sep 24 19:58:09 1991

Date: Tue, 24 Sep 91 19:57:03 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: Mark Rosenstein <mar@MIT.EDU>
Cc: reidmp@Athena.mit.edu, nschmidt@Athena.mit.edu, carla@Athena.mit.edu,
In-Reply-To: Mark Rosenstein's message of Tue, 24 Sep 91 12:20:36 -0400,
Reply-To: tytso@athena.mit.edu

   Date: Tue, 24 Sep 91 12:20:36 -0400
   From: Mark Rosenstein <mar@MIT.EDU>
   Sender: mar@MIT.EDU

   I just figured out what has been bothering me about these discussions.
   I approach file protection wanting everything to be open and world
   readable.  I have one directory called private for the few exceptions.
   When I create new directories, I want them to be readable.  Both NFS
   and AFS handle this case fine.

This is an old, old issue, dating back at least three or four years.
SIPB's Inessential Guide to Athena has a section called "File
Protection: How to be less fascist, and why you should" which tries to
educate users on this topic.  The arguments on both sides of the
argument are good; on one hand, you want people to be actually able to
use the file-sharing capabilities of a distributed filesystem.  On the
other hand, we have to recognize that most users will remain ignorant
about the system, and we shouldn't let them screw themselves in their
ignorance.

My personal opinion on the topic is that we should place a lot more
emphasis on training users to open up their home directories, and to
teach them about Unix/AFS file protections.  A simple first discipline
to teach them is to have them create a protected directory called
"~/private" or "~/closed", as Mark mentioned, and have them placed
things that they want to keep private in either their ~/Mail directory
or their ~/closed directory, and make everything else public.  

In any case, since I'm sure this education probably won't reach most of
the users, we still need to address the issue of the difference of mkdir
in AFS versus a mkdir in NFS.  I've hacked together a quick solution
which may start to address this problem.  Take a look at
/afs/net/user/tytso/src/mkdir/mkdir.c (there's a VAX binary in the same
directory).  It's very much of a kludge (I wouldn't advise looking at it
too soon after eating), but it should do the right thing in 90% of the
cases.  It doesn't make the problem go away, since you still can't
emulate Unix file protetions in AFS, but it's a step in the right
direction. 

						- Ted

home help back first fref pref prev next nref lref last post