[OpenAFS] Token Persistency and GUI Problems on Mac OS X

[Wei-Gung Sun]

Hi,

      I installed the latest OpenAFS (1.2.6) client for Mac OS X (10.1) on 
my Mac OS 10.1.5 box.  Few configuration steps were taken after the 
installation to create/update few files, CellServDB, ThisCell, and 
afsd.options that were under the openafs/etc directory on my 
Mac.  Everything seems working fine so far except the following:

1) Logout won't destroy token unless "unlog" first:
Explanation: Obtained token from "klog" at terminal window then logout from 
the account without "unlog" at terminal window.  After logging back in to 
the same account, the same token was still existed (if not expired) by 
typing "tokens" at terminal window.

2) GUI works inconsistently with command line operations:
Explanation: (Assume your local user name (short name) is same as your AFS 
user name)
I was told to change my local account uid to be same as my AFS id to have 
the OpenAFS client work on Mac OS X.  I did try on both to communicate with 
AFS as follows:

(1) Local uid was not changed to match AFS id:  After klog and obtaining 
token, worked great for command line operations only. Worked funny and 
unstable on GUI, sometimes even locked my system.

Via the GUI window, my client side was recognized as either Group or Other 
(depended on GID of file) but not Owner by file protection mode of each 
directory (or folder) in AFS, and AFS acl was not effective for owner of 
file even I got token.

After changing the Group/Other file protection mode for a directory to Read 
and Execute (i.e. r-x) permissions, I could modify any files under that 
directory through GUI even the file was read only after I chose to 
overwrite to it.  Therefore, without changing local uid, for GUI window 
only, file protection mode for Group or Other will take effect since the 
client side will not be treated as the Owner of directories in your AFS 
location.

(2) Local uid was changed to match AFS id: After klog and obtaining token, 
worked great for command line operations only.  One type of inconsistency I 
have found so far between command line and GUI was still the access 
prevention from file protection mode.

Via the GUI window, my client side was recognized as Owner by file 
protection mode of each directory (or folder) in AFS.  AFS acl did perform 
some capability to prevent system from being locked up when granting access 
to file/directory(folder), but if file protection mode for Owner of a 
directory has Read permission only, even you got token, you still do not 
have sufficient access privileges to get access to that directory (folder) 
unless the file protection mode for Owner of that directory has at least 
Read and Execute permission (i.e. r-x for Owner).

Thanks for you patience to read my test result and concerns so far.  I know 
to sync local uid to be same as AFS id can have the client work better than 
not doing it, but if you didn't do it carefully during the changing local 
uid process, you may lose some of files that were associated to your old 
local uid after you log back on to your account with new sync'ed uid.

The above concerns and problems, 1) logout won't destroy token unless 
"unlog" first (may be a security concern) and  2) GUI works inconsistently 
with command line operations, does anyone know or have fix or better 
work-around for them?  I would appreciate any helps.

Will Sun
(818) 354-2311