openssh unix dev - Feb 2004 - OPenAFS and OpenSSH replacing kafs

Would OpenSSH be willing to accept a modification similar to the one 
below to replace the kafs modification to get an AFS PAG and token?

The nice features of this are that it can be compiled in 
even if OpenAFS is not available. At runtime if the
dynamic library is present, it can be loaded and called.
A dynamic lib is used so the setpag is in the same process. 

It has been reported that the kafs code does not work with 
delegated gssapi credentials in OpenSSH-3.8. I have not had
this problem as I used a different method which this mod is 
based on. This proposed change would replace the calls to kafs.  

OpenAFS could then distribute the dynamic library, that would
get a PAG and fork/exec some program like aklog, or afslog to
actually get the token.  

The aklog or afslog could be distributed by OpenAFS or some
Kerberos vendor. 

The routine loaded is the get_afs_token routine that I proposed
last week but without the -setpag "kernel hack". It would have
setpag code added to it instead and this runs in the current
process avoiding the need to set the PAG in the parent process.   

The following compiles but I have not tested it. I am looking
for comments.

 Would OpenSSH be willing to add such a mod?

 Would OpenAFS be willing to distribute the dynamic library?
 ( I have sent this same message to the openafs-devel list yesterday
  but have not received and comments.)

 Would the Kerberos developers be willing to provide the 
 aklog  or afslog that accepted -p <path>  and an environment
 with the KRB5CCNAME in it?   


--- ,session.c	Mon Feb 23 07:01:27 2004
+++ session.c	Thu Feb 26 14:10:39 2004
@@ -58,9 +58,13 @@
 #include "session.h"
 #include "monitor_wrap.h"
 
+#ifdef ANL_AFS_PAG
+#include <dlfcn.h>
+#else
 #if defined(KRB5) && defined(USE_AFS)
 #include <kafs.h>
 #endif
+#endif
 
 #ifdef GSSAPI
 #include "ssh-gss.h"
@@ -1453,6 +1457,28 @@
 	 */
 	environ = env;
 
+
+#ifdef ANL_AFS_PAG
+	/* Get PAG and AFS token using external program and KRB5CCNAME */
+	if (options.kerberos_get_afs_token) {
+		void * handle;
+		int (*get_afs_token)(char * pgm, char ** env, 
+				char *homedir, int setpag);
+
+		debug("Getting AFS PAG and token");
+		handle = dlopen("/usr/lib/afs_get_token.so",0); /* needs a better
location */
+		
+		if (handle) {
+			get_afs_token = dlsym(handle, "get_afs_token");
+			if (get_afs_token) { 
+				debug("calling get_afs_token");
+				(*get_afs_token)(NULL, env, pw->pw_dir, 1);
+			}
+			dlclose(handle);
+		}
+	}
+#else
+
 #if defined(KRB5) && defined(USE_AFS)
 	/*
 	 * At this point, we check to see if AFS is active and if we have
@@ -1477,6 +1503,7 @@
 		krb5_afslog_home(s->authctxt->krb5_ctx,
 		    s->authctxt->krb5_fwd_ccache, NULL, NULL, pw->pw_dir);
 	}
+#endif
 #endif
 
 	/* Change current directory to the user\'s home directory. */

On Fri, Feb 27, 2004 at 05:23:38PM -0600, Douglas E. Engert
wrote:
>  Would OpenSSH be willing to add such a mod?
i don't see why sshd should play a dynamic linking game.

either the library has the symbol at compiletime
or not.

Markus asks:
> if GSSAPI is the great generic security server API it claims
> to be, then it can hide all this stuff from sshd.
Correct, the GSS-API has gaps, such as:

 - There's no way to make delegated GSS credentials available for
   acquisition through GSS_Acquire_cred()/GSS_Add_cred().

   See:

  
http://www.ietf.org/internet-drafts/draft-williams-gssapi-store-deleg-creds-00.txt

   for a proposed solution which involves adding a function,
   GSS_Store_cred(), for storing gss_cred_id_t's in the "current"
   credentials store.  Manipulation of credential stores is left as
   platform-specific, or for future extensions.

   The only objection I've had to this has been that GSS_Store_cred()
   does not seem to allow for per-session credential stores, however I
   do believe that PAM and GSS_Store_cred() could interact such that
   this is not an issue.

   This is the biggest gap in the GSS-API.


 - There's no way to inquire a mechanism for its "features." 
E.g.,
   there's no way to know if a mechanism indicated by
   GSS_Indicate_mechs() is SPNEGO or otherwise negotiates mechanisms,
   which, as we know, must not be used in SSHv2.


Note that authorization is not, however, an area where the GSS-API has
gaps, but it is an area which may be handled differently on different
platforms -- a consideration for portable code.

Cheers,

Nico
--