[OpenAFS] Two afs issues with Mac OS X

[Chaskiel M Grundman]

Excerpts from internet.computing.openafs.info: 9-Dec-101 [OpenAFS] Two
afs issues wi.. by tomstr@inf.ethz.ch 
>    In one implementation the token is valid in the process 
>    group (process subtree?) group that go the token.
process authentication group (pag) != process group.
An afs pag is represented by two additional groups in your unix
grouplist. The process group and session identifiers are not used.

>    I assume openafs for MacOS X is implementing the first model. 
>    If I remember correctly the Mach Implementations did the
>    same thing, while the Solaris ones stuck to the model with
>    validity on the whole workstation.
openafs impliments both models. By default, your processes do not have
pags, and tokens are shared accross the entire machine. If you have an
AFS-aware login program, or use the 'pagsh' command, then processes
descended from that will be in a pag, and will not share tokens with the
rest of the machine.

>    This behavior causes problems with MacOS X client/server.
>    As far as I know I can only get a token in the terminal window with
>    a commandline shell. But so the graphic shell called "Finder", 
>    that drives really everything in the Macintosh cannot see my AFS
>    token and therefore does not get my AFS access rights. This is sad
>    since this restricts AFS use to the commandline mode only.
Are you sure that the finder does not have your authentication, or are
you taking it's indications of files and folders as 'read only' or 'not
accessible' at face value? The finder is making decisions about the
accessibility of files and folders by using the stat system call and
examining the files' owner, group, and mode bits, so unless your unix
uid and afs id are the same, it will lie. There has long been a
mechanism in unix for dealing with issues like this (the 'access' system
call), but the finder is not using it. 

I had thought that the finder's behavior was advisory (aka it would do
the operations anyway if you ask it to), but it turns out that that is
not the case. There are two possible workarounds: You can either change
the modes on all your files and directories to 0777 or 0666 (which will
likely break other software, like ssh), or you can set your unix uid to
the same value as your pts id, and only use the finder in your primary
cell.


> 2. How do I restrict the AFS world visible in the /afs mount point 
>    of my client to a reasonable subset of all afs sites in the
>    world.
The readme included with the macos openafs installer suggests
petitioning your afs admins for an alternate root.afs volume that has
fewer items in it. There is no good solution to this problem.


>  I did try to edit the number of sites in the CellServDB file
>   of my clients, but then the entire world was visible again...    
>   Did my client check a CellServDB of my home cell as well?
I'm not sure. Are you sure you rebooted after changing the CellServDB?
does 'fs listcells' have more items that the cellservdb does? (to the
other readers: while the macos x binaries do have afsdb enabled, it
doesn't seem to actually do anything in the cache manager on the macos x
machine I have, so I don't think that is what is happening here)