Greetings all: Here's a fun one:

coda server:
=================================================
[r...@sandbox1 ~]# cat /vice/codaauth2.conf
4 {
authorities {
  realm_short {
    authmethod = kerberos5
    methodopts {
      krb5realm = KERBEROS.REALM
    }
  }
}
}
[r...@sandbox1 ~]# /vice/bin/pdbtool list|tail -11
USER coda_user
*  id: 83901
*  belongs to groups: [ -12 ]
*  cps: [ -12 83901 ]
*  owns groups: [ -12 ]
GROUP GROUP:coda_user OWNED BY coda_user
*  id: -12
*  owner id: 83901
*  belongs to no groups
*  cps: [ -12 ]
* has members: [ 83901 ]


coda client:
=================================================
[r...@sandbox4 ~]# cat .codafs/clog/pref
5 {
loginto = realm_short
identities {
  realm_short {
    desc = realm_short
    identity = coda_user/realm_sh...@coda.realm
  }
}
[r...@sandbox4 ~]# ctokens @coda.realm
Tokens [local user id: U_GetLocalTokens: Transport endpoint is not connected
root]
[r...@sandbox4 ~]# clog -keytab ~/.codafs/clog/krb5.keytab
[r...@sandbox4 ~]# ctokens @coda.realm Tokens [local user id: root]
  @coda.realm
      Coda user id:    484
Expiration time: Thu Feb 25 04:48:07 2010 [r...@sandbox4 ~]# grep 484 /etc/{passwd,group}


Where in the world is uid 484?? The ACL's very rightfully lock this "484" user out of coda_user's coda share/dir. It is noteworthy to state that when I clog with the coda admin user, the pdbtool UID and the ctokens UID match thereby allowing the ACLs to grant appropriate access. When I use coda password auth it is the same non-user UID (no change).

Any ideas??

Regards,
-Don
{void}

Reply via email to