[OpenAFS-devel] aklog on MacOS X was Re: Service Ticket Questions

[Jeffrey Hutzelman]

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
>> translator).
>
> 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 6.4.6.1 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
> PAG's.

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 
different cells.


  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.

Ditto.


Off to dinner.

-- Jeff