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

[Douglas E. Engert]

Russ Allbery wrote:
> Douglas E Engert <deengert@anl.gov> writes:
> 
>>Russ Allbery wrote:
> 
> 
>>>This is already what Debian does,
> 
> 
>>Thats part of the argument, its a single vendor's solution. What about
>>the other vendors, including SUN, HP, IBM, SGI, MAC and other Linux.
> 
> 
> The only piece of code that's in Debian related to this that hasn't been
> assembled from freely available software is a small PAM module that calls
> aklog -setpag, so I honestly think we're in about the same place here.
> Like I said, it's really all already out there except for the PAG piece.
>

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.

> 
>>That is the intent of gafstokens. It uses syscall or on linux the /proc
>>file to set the PAG. It uses no AFS headers (but could) or libs, is PIC
>>code, and protects itself by trapping some signals. It fork/execs an
>>aklog like program to get the tokens. It compiles to libgafstoken.so
> 
> 
> I think this would be great.  This sounds like exactly the right solution
> to the PAG problem to me.  Previously, one had to use KTH Kerberos or
> Derrick's variation on the same idea to get the same effect, KTH Kerberos
> has various portability problems to recent Linux versions and builds quite
> a bit more than just that library, and none of that is conveniently there
> when one builds AFS.
> 
> 
>>I agree, For the PAG it could even be a macro, as it really comes down
>>to a syscall.
> 
> 
> It's probably better as a function, though, just in case.  One never can
> tell what additional complexity may be needed long-term.

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.

> 
> 
>>I would rather see two seperate libs, as the PAG needs to be obtained
>>from the session leader, which usually means it has to be called from
>>some system deamon, like sshd, or dtlogin,or gdm usually from PAM.
> 
> 
> 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 want to be able to use OpenAFS on systems who provide their own
Kerberos libs. If/when OpenAFS adds full Kerberos support for using
K5 tickets as tokens, will there be conflicts? I have run into these
types of problems with working with DCE.

Hopefully the only part of AFS that needs to be dragged into login is setpag.

> I
> *don't* advocate putting any of the ticket munging logic into the library,
> just the minimal "here's a binary blob that I already formatted
> appropriately; please stuff it into the kernel and call it a token"
> interface.  It makes packaging and other things much easier if we don't
> increase the number of libraries unnecessarily.

I would say that you would have to link in the "ticket munging logic"
with the routines to stuff the token into the kernel. But this can
be separate from the setpag.

> 
> 
>>The tokens on the other hand can be obtained from a child process like
>>aklog.
> 
> 
> Forking external programs out of a PAM module is an ugly way of getting
> tokens. 

I know its ugly, but it works and avoids a lot of problems.

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.

> It's probably the best currently available way of doing it while
> there are three hundred different aklog implementations that all do
> slightly different things, but hopefully that won't be the case in the
> long run as matters converge on K5. 

Again, I want to be able to use OpenAFS on systems which provide their
own versions of Kerberos.  The problem is you need to authenticate,
get a PAG and AFS token all in the same process usually via PAM.
The vendor's version of Kerberos may not be the version used within
OpenAFS, so even though they may all be in the same process, they may
not be able to share libs, or krb5_context. At least the multiple
implementations of Kerberos agree on a common ticket cache format and
you can't count on much more.

>  While I think supporting the fork and
> exec hack is the right thing to do for the time being, I don't want to get
> locked into any system that prevents us from doing the right thing down
> the road. 

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.

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

> 

-- 

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