[OpenAFS-devel] OpenSSH, OpenAFS, Heimdal KerberosandMITKerberos

[Douglas E. Engert]

Jeffrey Hutzelman wrote:
> 
> On Monday, January 26, 2004 15:02:54 -0600 "Douglas E. Engert"
> <deengert@anl.gov> wrote:
> 
> > Well the PAG needs to be set. The code with the kafs sets it in the
> > current process, which is the process I would have fork and exec aklog,
> > so if they move the code in either case the PAG will be wrong.
> 
> Yup.
> 
> > OK. The situation I would like to avoid is vendors packaging OpenSSH
> > executables that don't have any hooks in them to set the PAG or get a
> > token, which is the  case today.
> 
> Actually, PAM was a perfectly fine hook, when PAM session modules were
> still called in the inheritance chain of the user's shell.  This only
> became broken in OpenSSH 3.7.1.  If they fix it, we can use a PAM module to
> set a PAG.

I agree. PAM provides the run time environment that I would want to see.
And as you point out it is a problem where OpenSSH is calling PAM
from the privsep process.  

I thing we are in agreement. But what can we expect from them? 
They are willing to call the kafs code. Is there some argument 
we can use to have them call the PAM session module from the right
process? 

I was taking the approach that fixing PAM would be a lot harder then
defining an AFS hook, and adding it in their code where the kafs
code would have been added. 

> 
> > Is the PAG mechanisum you expect to endup with on Linux going to be a
> > standard feature, i.e. always in the kernel? If not and the setpag of
> > parent is not available either, that could be a step backward.
> 
> It's still very unclear what will happen.  It's politically very messy.
> 
> But really, setpag-in-parent is a kludge which breaks a fundamental
> abstraction. 

I know, but it did make it easier.  

> It was done entirely so that the designers of the original
> Andrew system could provide newpag-like functionality without having to
> actually start a new shell, because for some reason they thought that would
> make their lives easier.  Today, I see it used only so that people can do
> in a subprocess what they'd have to do in the same process for any other
> mechanism.  The call to setpag() belongs at the same place you call
> setgroups(), setgid(), setuid(), and so on; not in a separate process.
> I'll not be the slightest bit sorry to see this "feature" go away.

I am not either, as long as you can get the OS to support a setpag
system call, and get devlopers to call setpag() along with the
other set*() routines. If Linux adds the PAG, and setpag() call that
would be good. 

So the support for the setpag of the parent may still be usefull on
other systems that do not define thier own PAG which is usable by AFS. 


> 
> -- Jeff

-- 

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