[OpenAFS] unix permissions and MacOS X

[Alexei Kosut]

On Tue, Mar 12, 2002 at 06:44:53PM -0600, steve rader wrote:
> a simple kludge i've used is to 
> 
>  find . -print | xargs chmod go+r
> 
> in any directory trees you want to show up in the finder
> or other carbon apps.  (i don't remember, but i may have
> also done "find . -type d -print | xargs chmod go+x"?)
> 
> afs ignores the bits so why not set 'em?  is there anything
> really wrong with that?

Nothing really wrong; it cetainly works.  The following problems come
to mind, though:

1. It takes forever if you have a lot files to view.

2. You can only do it for directories you have write permission for.
   In my case that's but a tiny fraction of the directories I have
   read permission for.  And asking the owner of every directory I
   want to access to change their permissions isn't really viable.

   I suppose I could ask our cell administrators to run a command like
   that on everything in AFS.  But I doubt they'd agree...

3. It's not something that's easily explainable to end users.  This is
   an important factor to me; I need people to be able to use AFS from
   the Mac OS X desktop without them every having to open the
   Terminal, let alone type commands they may not understand or get
   right.

   I also have this problem with another solution I've seen; setting
   the Mac OS X uid to be the same as the AFS one.  It's hard for a
   novice user to do (involving NetInfo Manager, changing the owner on
   existing files, etc...), and has the further disadvantage that it
   only works for files that you actually "own" in AFS.

4. You have to do it over every time you add new files or permissions
   get changed elsewhere (which they will).

5. There may be files for which you mean to have read or write
   permission bits turned off, for a reason; RCS files, for example.
   Going and turning them all on may cause problems later.

Making the change in the client means that you don't have to change
the actual AFS filesystem at all.  And given that this is specifically
a Mac OS X bug, it makes a lot more sense to me to work around it in
the Mac OS X client (given that there *are* such workarounds) than it
does to do extra work to coerce the files AFS to adhere to Mac OS X's
bugs.

-- 
Alexei Kosut <akosut@cs.stanford.edu> <http://www.stanford.edu/~akosut/>