Greetings all: 

> On Tue, Feb 23, 2010 at 08:03:48PM -0800, root wrote:
>> [root_at_sandbox4 ~]# ctokens @coda.realm  
>> 
>> Tokens [local user id: root]  
>> 
>>   @coda.realm
>>       Coda user id:    484
>>       Expiration time: Thu Feb 25 04:48:07 2010  
>> 
>> [root_at_sandbox4 ~]# grep 484 /etc/{passwd,group}  
>> 
>>  
>> 
>> Where in the world is uid 484??  The ACL's very rightfully lock this "484" 
> 
> Why are you looking in /etc in the first hand?

It was the last attempt at making sense of the ID mismatch. 


> Coda ids [are its internal business and they] have nothing to do with
> the local clients' ideas of uids and gids (the ideas are different on
> different client hosts, how can a Coda server be concerned about them?) 
> 
> Unfortunately Coda for historical reasons still exposes its internal
> "uid" as the "owner uid" in the results of stat() calls. This does not
> have any reason and contributes to the confusion for many people between
> local and global entities. This might be usable for troubleshooting but
> otherwise it seriously hinders understanding. This is one of the pityful
> heritages from AFS.

I am not understanding how this explains what I'm seeing. 

When I am logged in to coda as coda_admin, the ctokens ID matches the 
pdbtool ID, and the ACL grants access to view the admin shares/dirs. 

When I am logged in to coda as coda_user, the ctokens ID does NOT match the 
pdbtool ID, and the ACL does NOT grant access to view the user shares/dirs. 

The coda admin was created using pdbtool clone user feature (from the coda 
realmadmin user), while the coda user was created using pdbtool new user 
feature. 


In any case, there is no such ID as 484, so I have no idea where coda is 
getting that ID from. 


Here is pdbtool and ctokens output to illustrate my situation: 

sandbox1# /vice/bin/pdbtool list
USER realmadmin
 *  id: 83885
 *  belongs to groups: [ -1 ]
 *  cps: [ -1 83885 ]
 *  owns groups: [ -1 ]
USER codaadmin
 *  id: 83886
 *  belongs to groups: [ -1 ]
 *  cps: [ -1 83886 ]
 *  owns groups: [ -1 ]
USER codauser
 *  id: 83896
 *  belongs to groups: [ -8 ]
 *  cps: [ -8 83896 ]
 *  owns groups: [ -8 ]
GROUP GROUP:codauser OWNED BY codauser
 *  id: -8
 *  owner id: 83896
 *  belongs to no groups
 *  cps: [ -8 ]
 *  has members: [ 83896 ]
GROUP System:Administrators OWNED BY realmadmin
 *  id: -1
 *  owner id: 83885
 *  belongs to no groups
 *  cps: [ -1 ]
 *  has members: [ 83885 83886 ] 


sandbox4# cunlog @coda.realm; clog admin -keytab admin-krb5.keytab; ctokens 
@coda.realm 

Tokens [local user id: root] 

   @coda.realm
       Coda user id:    83886 


sandbox4# cunlog @coda.realm; clog user -keytab user-krb5.keytab; ctokens 
@coda.realm 

Tokens [local user id: root] 

   @coda.realm
       Coda user id:    484 


Logged in as coda admin, IDs match and everything works.  Logged in as any 
other coda user, and IDs do NOT match, and cannot access anything. 

Here are the ACLs, they're very strait forward: 

sandbox1# cfs la /coda/coda.realm/
     System:AnyUser  rl
System:Administrators  rlidwka 

sandbox1# cfs la /coda/coda.realm/codauser
GROUP:codauser  rlidwk
System:Administrators  rlidwka 


Any insight is greatly appreciated.  This has had us stumped for days. 

Regards,
 -Don
{void}