I don't disagree with your proposal at all. Sounds good. It should make it easier to fix/change things in the future.

But. . .

Isn't the reason this keeps coming up that AFS client doesn't (can't?) behave like a normal Kerberos application and just get it's own service ticket when it needs one (based on an existing tgt)? The real reason this doesn't happen is that tickets are stored in a file in /tmp, but it's a different set of file system code inside the kernel that would need to access it to request the service ticket.

Can't we figure a way to just make the kernel module get the service ticket (token) automatically, or fail if there is no tgt? That would make the whole problem go away and AFS would no longer need the special attention it does now.

I note that on MacOS X tickets are stored in a MACH "security context" which acts a lot like a PAG. Furthermore it's accessible inside the kernel. Doesn't Windows have some similar in-memory storage mechanism?

Has anyone thought about how congruent PAGs and terminal sessions are? I think X11 defined the latter, and Kerberos has tried to tie in to them rather than import the PAG concept.

At 11:21 AM -0600 1/26/04, Douglas E. Engert wrote:
Rather then implementing kafs in MIT Kerberos, I would like to
suggest an alternative which has advantages to all parties.

The OpenSSH sshd needs to do two things:
   (1) sets a PAG in the kernel,
   (2) obtains an AFS token storing it in the kernel.

It can use the Kerberos credentials either obtained via GSSAPI
delegation, PAM or other kerberos login code in the sshd.

The above two actions can be accomplished by a separate process,
which can be forked and execd by the sshd and passed the environment
which may have a KREB5CCNAME pointing at the Kerberos ticket cache
Other parameters such as the home directory could also be passed.


This would then allow simple code in OpenSSH that does not depend on OpenAFS, Hiemdal or MIT code to fork/exec the process that does all the work. This would be called by the process that would eventially become the user's shell process and is run as the user.

OpenSSH could be built on systems that may or may not have AFS
installed and run on a system with or without AFS.  The decision
is based on the existence of the executable and any options
in sshd_config.

In its simplest form, all that is needed is:

system("/usr/ssh/libexec/aklog -setpag")

This is a little over simplified as there should be a test if the
executable exists, processing of some return codes, making sure the
environment is set, setting some time limit. etc. But the point is
there is no compile dependence on OpenAFS, MIT or Hiemdal by the
OpenSSH sshd, and any failure of the process will not effect the sshd.




We have been using something like this for years which issues a
syscall to set a PAG for the current process, then fork/exec ak5log.
Our current mode to OpenSSH in session.c is as  simple as:

krb5_afs_pag_env(NULL, env);

It is currently built with the MIT Kerberos code for historic reasons,
but could be seperate as it has no real dependency on the MIT code.

I would hope that the members of the OpenSSH community who use OpenAFS,
Hiemdal and/or MIT could agree on a simple command line interface that
would encourage the builders of OpenSSH to always have this enabled.


--

 Douglas E. Engert  <[EMAIL PROTECTED]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444


--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
________________________________________________
Kerberos mailing list           [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to