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}