On Mon, Apr 30, 2001 at 10:40:20AM -0400, Ken Raeburn wrote: > Nicolas Williams <Nicolas.Williams@ubsw.com> writes: > > > I don't know about that. It does sound somewhat useful, though I'm > > > not jumping up and down with excitement. I just think there are > > > issues to be addressed first. > > > > I'd like to understand why *this* feature would be so needed anywhere... > > Being able to walk up to a server and log in as root with my password > would be so much more convenient than having to remember a collection > of root passwords for machines maintained by different groups, all of > whom trust me to log in as root to their servers. Avoiding having to > type both username and principal name would be nice too. I think you could do the following: - use PAM aware /bin/login - write a PAM module which, if PAM_USER == root, prompts for a different username to authenticate, then check the user's authorization to access the root account somehow (e.g., use pam_wheel). Perhaps this could be used with pam_stack. auth required pam_su auth required pam_unix Here pam_su would prompt for a different username and would, like pam_stack, initialize a new PAM handle using 'su' as the service name and the new username as the PAM_USER and then pam_su would call pam_authenticate() with the new handle, and return the same error. For non-root users pam_su would return PAM_IGNORE. See? The solution is to prompt the user who would log in as root for their actual username. Note that for console logins you can use a vendor-provided /bin/login and any of a number of PAM_KRB5 modules -- i.e., login.krb5 is not absolutely necessary for console logins. > > Why keep extending the account authorization code in MIT krb5 when PAM > > is available? (Short answer: MIT krb5 knows not PAM at this moment, sigh). > > A while ago djm submitted some patches to fix that. I've asked him to > check a couple of things, but I would like to get something like it in > soon. My main issue was avoiding code duplication -- can we use a > krb5 PAM module, and a PAM-based login program with little or no > krb5-specific stuff, and a stub implementing the PAM API (but just for > the krb5 module, with no configuration options) for systems that don't > have PAM already, or do we have to maintain both flavors of login > code? If we can do the former, it seems like the far better approach, > even if it's a bit more work in the short term. Well, Linux-PAM is rather portable (*)and it's distributed under a BSD license... And most modern Unix and Unix-like OSs support PAM. If not PAM, then SIA. And I think that telnetd -a valid|user|other|none handling can and should be moved to login + PAM. > Ken (*) Linux-PAM is used by various Linux distros and FreeBSD. I hear it's been used by some to replace Solaris PAM, though that seems difficult. We've just paid to have it ported to a legacy BSD-ish OS. Cheers, Nico --