[OpenAFS-devel] Simplified integration of OpenAFS, Kerberos SSH and PAM (again)

[Russ Allbery]

Douglas E Engert <deengert@anl.gov> writes:

> aklog -setpag is another problem, as a child being able to change the
> parent process is sort of against unix basic principals. I don't think
> this works on all systems either.

Right, I agree.  I think that newer kernel models are going to make this
difficult to maintain.  This is just what libpam-openafs-session is doing
right now because it's what worked without requiring libraries not
suitable for linking to a PAM module.

> What I was implying is that the only "AFS" code is really a syscall on
> most systems, and this is implemented by an internal function.  On
> linux, the gafstoken has a proc_afs_syscall function to open
> /proc/fs/openafs/afs_ioctl or /proc/fs/nnpfs/afs_ioctl This came from
> the OpenAFS code.

Right, yeah.  It's a very simple function in most (possibly all) cases.

>> I don't think that's a good justification for making them two separate
>> libraries.  There's no reason why the PAM module and aklog can't link
>> against the same library, and both calls have a very simple ABI.

> The justification is the unknown complexity that is involved when
> multiple PAM routines are used, and the libs that they drag in which may
> conflict with other PAM routines. They can drag in threads, OpenSSL,
> multiple versions of Kerberos.

I think you're missing my point.

The "make this a token" function doesn't link against any Kerberos
libraries.  It only has a little more complexity than the setpag
function.  All it does is take the blob of token that one has come up with
via magical means and push it into the kernel.  It is the syscall
interface; nothing more or less.

As such, it clearly doesn't drag in threads, OpenSSL, multiple versions of
Kerberos, or anything else, and it won't cause problems for vendors and
won't cause conflicts with native libraries.  It's just the bit that
OpenAFS has to provide to let you talk to the kernel layer.

Under the hood, it may have to do complex things to attach to a Linux
kernel keyring or whatever the flavor of the week is for how one shoves a
token through the user-to-kernel interface, but it shouldn't be doing any
complex *Kerberos* things.  In fact, this routine should be entirely
ignorant of the existence of Kerberos; my conception of it is that it
would take the name of the cell, a blob of data, and maybe some flags like
overwrite and then shove that at the kernel and let the AFS module
interpret the data.

Maybe I'm missing some subtlety of how this interface works that would
cause this to be harder than it sounds.

The idea is that your aklog implementation would then use this routine to
push the token into the kernel, after it's done whatever it has to do in
Kerberos terms to get the thing ready.  And the library that provided this
routine and the setpag routine would basically be the "AFS system call
library" with no dependencies on any other libraries at all.  It's job
would just be to expose the system calls that userspace programs that
aren't AFS programs need to use as functions with a highly stable ABI.

> I would say that you would have to link in the "ticket munging logic"
> with the routines to stuff the token into the kernel.

Right.

> But this can be separate from the setpag.

It can be, but I don't see the point in maintaining two tiny shared
libraries, each of which contains only one function, when you could just
combine them into the "AFS system call library" that exports two equally
simple (ABI-wise) functions.

I have not, however, written an aklog myself (and I know you have way more
experience with this than I am), so maybe I'm confused about what the
interface with the kernel looks like.

> Another way to do this is to ask the AFS Kernel modules to have a helper
> process to get tokens using the ticket cache. If AFS every wants to have
> different principals for different AFS servers, it will need something
> like this.

Personally, I think it's more likely that the trend will go the other
direction and people are going to start wanting to put Kerberos ticket
caches in the kernel the way tokens are now.  I could be wrong, but the
kernel call back down into user space to try to find the user's ticket
cache seems fraught with danger to me.  The kernel is actually better
positioned to keep ticket caches attached to the right processes and make
sure that only authorized processes can get at them.

> Or locked out of using OpenAFS on some system with its own Kerberos
> where the APIs (other then GSS) are not exposed, because OpenAFS uses
> conflicting libraries. I don't want to have to replace Kerberos on a
> system to get OpenAFS to work.

Sure, I agree.  Forking needs to be supported for right now.

> I think we are pretty much in agreement. What I would like to see is
> OpenAFS pick up on these.

I'm happy to help do the work.  I'm a little unclear right now on what
direction the gatekeepers want to go with this whole area.  Is there
anything concrete that those of us who are fighting with these problems
can do to help with that decision-making process?  Provide patches that
are ready to apply?  Help clean out the OpenAFS bug database for
completely unrelated issues so that we can free up your time to think
about this?  :)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>