Douglas E Engert <[EMAIL PROTECTED]> writes: > Feature requests:
> * all aklog type programs support the -p <path> option, so that > the user's home directory can be passed, so a token for the > user's cell can be obtained. This isn't good default behavior since, for instance, it will fail to get tokens when the user's home directory isn't in AFS. I added an option to request this behavior, though. (At some point, I'm going to have to figure out what to do if the program to run isn't a simple program name but has some options attached. Oh well, I can put that off for right now.) > * Should a failure to get a PAG or token be a critical failure? > i.e. if the routine is called on a system without AFS, or the > AFS kernel extensions failed to load, which should sshd do? > I would say continue on, but log a message. You return > PAM_SESSION_ERR in a lot of these situations. Should this be > an option? Well, those are two different questions. If AFS isn't available, the module should log a message and return success. That's what it does now. If AFS *is* available, but the module was unable to obtain a PAG, it should fail. Otherwise it could introduce a security vulnerability, by leaving the user in the same PAG as sshd, for instance. Not obtaining the token is more borderline, but after thinking about it for a moment, I think it makes more sense to log an error message and then return success. I'd rather not make this an option unless that strikes someone as bad behavior for their environment. > * Add support to trap signals around any calls to the AFS kernel > extensions. This really only applies if syscall is used. This > will keep a failure of AFS to load for keeping login to work. I was going to punt on anything other than Linux for the built-in AFS syscall support, but after thinking about, I think I can get the system call number from the OpenAFS headers and add the other syscall testing code for the systems where this is easy. That won't cover AIX, but AIX doesn't use PAM anyway so far as I know. I'm going to work on this next. > * Don't allow the aklog program to write to stdout or stderr, > as the messages may be misinterpreted by the client, rsh for > example could have problems. Something like this is the > exec'ed process: > close(1); open("/dev/null",O_WR_ONLY"); > close(2); open("/dev/null",O_WR_ONLY"); Done. > * You specifically check for KRB5CCNAME, and only call the aklog > if it is present. It is really up to the aklog program to find > the credentials, and it should still be called. I don't agree for the default behavior; I don't want aklog picking up some random Kerberos ticket cache and obtaining tokens that may potentially be wrong. However, I've added an option saying to always run aklog that people can turn on if they choose. > (1) On some systems like HP_UX that does not support pam_env, > the KRB5CCNAME may not be set, yet tickets are available, > using the default uid based cache name. This is a different problem that should be solved by the PAM module creating a KRB5CCNAME for HP-UX in that case when possible, probably using the same method that you use in pam_afs2. That's on my list to look at, but isn't one of my top priorities. Is there any hope that HP-UX will add the PAM environment functions? I suppose hoping for HP-UX to join the modern world is kind of doomed at this point; it's probably a mostly dead OS as development goes judging from the direction of HP's products. > (2) You are assuming that Kerberos is required. There are some > AFS sites that run Globus, and use gssklog with the GLOBUS > GSI using certificates to get an AFS token. Right, those sites should use the new option. > * Do you want to call it pam_afs_session? Sam's routine has the same > name. Should you use a different name? Your routine can be also be > called from auth for pam_setcred. So why does it have _session? > How about pam_afs3. Sam's module is called pam_openafs_session (or pam_openafs-krb5 in its source). I picked pam_afs_session so that it doesn't conflict. pam_setcred is actually a session function as far as I'm concerned. I'm not sure why PAM stuck it in the auth group, and we're stuck with that now, but I don't think it's inconsistent for a session module to provide a pam_sm_setcred. I'd rather avoid something generic like pam_afs3; for one, afs3 is a specific protocol and that may confuse people, and for another, it doesn't say much about what the module does. I would just call it pam_aklog except that I plan on adding support (optional) for calling the kafs functions to obtain tokens directly. > +*-solaris*) > + if test "x${CC}" = xgcc ; then > + LDFLAGS="-Wl,-z,muldefs $LDFLAGS" > + else > + LDFLAGS="-z muldefs $LDFLAGS" > + fi > + ;; > esac This looks wrong. Why do you have to allow for multiply-defined symbols on Solaris? The other header changes have been applied, and I'm working on the syscall abstraction now. As soon as I finish that and write a man page, I'll release a 0.2 release. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info