[OpenAFS-devel] aklog on MacOS X was Re: Service Ticket Questions
jhutz at cmu.edu
Mon Mar 27 22:34:23 EST 2006
On Monday, March 27, 2006 06:32:45 PM -0800 "Henry B. Hotz"
<hotz at jpl.nasa.gov> wrote:
> On Mar 27, 2006, at 4:48 PM, Jeffrey Hutzelman wrote:
>> On Monday, March 20, 2006 01:19:08 AM -0800 "Henry B. Hotz"
>> <hotz at jpl.nasa.gov> wrote:
>>> Just to be clear my desire is that OpenAFS provide a documented
>>> interface (like Heimdal kafs) that can be used by different people on
>>> different OS's to provide whatever hooks are appropriate to that OS.
>> OpenAFS provides a stable, documented API for examining and
>> manipulating tokens and PAG's, in the form of the 'pioctl' and
>> 'setpag' calls in libsys (if you'd rather not have Rx dependencies,
>> you can use 'lpioctl' and 'lsetpag' instead, but then you sacrifice
>> the ability for your application to work correctly with an NFS
> Man page? (At least the aklog program has a man page.)
pioctl is documented in in the AFS 3 Programmers's Reference, at FS/CM
6.4.1, followed by documentation for individual ioctl's. setpag does not
appear to be documented in that source; perhaps it was considered too
obvious (more likely, there simply was no public documentation of the
internals of the AFS syscall interface, and among calls used by other than
afsd and the fileserver, setpag is unique in that it is not a pioctl).
Warning: The description of VIOCSETTOK at 220.127.116.11 incorrectly describes the
first optional field as "a longword which is set to a non-zero value if the
cell in which these tokens were generated is to be marked as the caller's
primary cell". Due to change introduced in AFS 3.3a, the 0x8000 bit of
this field actually means set-pag-in-parent.
Sorry, no actual man pages for section 3 yet. I presume they're next on
the list, after Russ has had a chance to breathe.
> Only if it isn't possible to cause the discrepancy to go away. If you
> can keep the two stores consistent then you have done your users a big
> favor by reducing the complexity of their interface.
Except, as I mentioned in my previous message, that you screw people who
are trying to do things which depend on them being separate. Like using
different identities for different cells at the same time. Or running an
application which uses Kerberos in such a way that file accesses it does
don't automatically trigger using your credentials to access AFS.
> I think the status quo stinks. I think this is a problem. (I don't
> deny that AFS has other, bigger problems.) It's been a problem for so
> long that everyone takes it for granted and writes FAQ entries instead
> of tying to find ways to fix it. While you may disagree, I would hope
> that you don't prevent others from trying.
You're welcome to make your environment behave however you want.
If you want to have an aklog that deletes tickets from the ccache if it
fails to set tokens, go ahead. Or you could do one that uses a memory
cache and never stores the AFS ticket into the ccache at all, as was
suggested earlier. Oh, except you want the user to think they have a
ticket in their cache if there happens to be a token.
>> - pagsh (i.e. changing PAG's without changing ccache's)
>> - changing ccache's without changing PAG's
> These two only become relevant when we have PAG's. Currently we don't
> on MacOS.
False. If you don't have PAG's, then _any_ change of ccache is done
without changing PAG's.
Also, please understand I'm discussing your proposal in the context of AFS
and Kerberos as cross-platform systems. A significant difference in
behavior on a single platform is to be avoided.
> If I ruled the universe I would require an Apple PAG mechanism that was
> identical to a ccache and had an "inspector"-like UI so you could look
> at what tickets/tokens a given window had. Also would give you a
> "newPAG" button you could apply. I doubt I can get this, even if I put
> the time into defining it properly, but it would be cool.
Yeah, that'd be neat.
> I have a request in with MIT to provide ccache functionality closer to
Which will have the same problems we're having making PAG's work.
>> - explicit klog
> Obsolete, no longer supported. ;-)
Yes it is. Give me a new way to get tokens with different identities in
At least use klog.krb (which should
> create ccache entries and keep things in sync, but probably doesn't.)
Obsolete; don't use that.
>> - explicit unlog (without kdestroy)
> Should do a kdestroy.
Unless that's not what I want.
>> - explicit kdestroy (without unlog)
> Should do an unlog.
Off to dinner.
More information about the krbdev