I realized I didn't say anything useful the last time, so I thought I'd
post again with what I observed related to this error.
All this assumes that the user with uid==502 is logged in and has a valid
TGT in the credentials cache:
- upcalls with uid==0 would fail. This makes sense, but since I needed
system Ops related to NFSv4 such as Renew to work, I mapped uid 0 to
the uid of the user that did the mount (ie 502 in this case).
--> when uid 0 was replaced with 502 in the upcall, it worked fine.
- I still saw some of these errors for uid == -2. (I presume that some
daemon is poking at the file system, but haven't yet tracked that out.
Someone was nice enough to email me a dtrace script to do this, but I
haven't gotten around to using it yet.)
To see if it was caused by the wrong uid, I tried mapping the uid of -2
to 502, like I had done for the system Ops. (Wouldn't make sense to do
this for production code, it was just an experiment.)
--> Still failed with the error, even though the upcall had the "correct"
uid as argument.
So, it seems that some processes/threads can't authenticate even if the
uid is correct. I suspect it has something to do with accessing the
credentials cache (which I understand lives in VM on Leopard). When it
comes to control of access to a VM object on the Mach side of things,
I know diddly about it, so this is just a wild guess.
Hopefully this might be of some use? rick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/email@hidden
