(Illustration by Gaich Muramatsu)
>> >What does your /vice/auth2/AuthLog say at the time of clog? >> >> 18:13:01 vid = 83886 >> 18:13:01 AuthNewConn(0x7da9cdba, 0, 66, 2, 83886) >> 22:11:47 vid = 484 >> 22:11:47 AuthNewConn(0x72199dd5, 0, 66, 2, 484) >> >> Where is coda getting this ID? Clearly it believes there is a 484, but >> executing: pdbtool export /tmp/file1 /tmp/file2; grep 484 /tmp/file? >> results in null output. > > It is Kerberos who produces the account name from the ticket the auth > daemon acquires with the help of the data sent by the client. If Kerberos > would happen to produce a string "484", then the suthentication daemon > takes it literally and transforms to the numerical id. I can't be understanding this correctly, am I? Because my kerberos user has the string "484" in it, which it does (along with a few other numbers), coda mangles the coda _UID_ to match this random string in the kerberos _username_? Wouldn't it make a touch more since to simply use the coda UID as the coda UID? This cannot be the desired behavior, is it? > To make it easier to analyze I wouls ask you to make the corresponding > clog using Coda password. You do not have to change anything in the > setup, just create a password for an account and tell clog to use the > codapassword method. Nor use the codaauth service, I should think (nor perhaps even the DNS SRV records?). So noted for the future, but not needed now. I have confirmed. It is as you suspected. As based on the above: If there is a number in the kerberos username, coda drops it's internal coda UID in favor of the first integral number fragment in the kerberos username. This, of course, munges authentication and the associated ACLs that have been based on the _actual_ internal coda UID. I've updated my random username generation algorithm to avoid numbers to work around this behavior and, low and behold, no more issue. I cannot thank you enough for your assistance. I simply don't know that I would have ever stumbled upon that correlation. Certainly not soon enough, at any rate. Regards, -Don {void}Received on 2010-03-08 04:55:19