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

[Douglas E. Engert]

Russ Allbery wrote:

> 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.
>
(The pam_afs2 could also be used from the pam_sm_setcred after the pam_krb5
and is usefull on Solaris with dtsesion for screen unlock.)

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

AIX was messy, but I have not looked at AIX in a few years.

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

OK, the same lib could have the setpag routine and ktc_setToken like routine
as Jeff points out as long as it does not require any extra libs.

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

OK, as long as it is simple, and does not drag in extra stuff.

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

Yes this might happen, NFSv4, gss-rpc etc. But this is hard to do,
and may tak a while, and different vendors might do it differently as well.

> 
> 
>>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?  :)
> 

I could not have said it better. Count me in on this too.

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444