[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Any interest in krb5_userok_principals ?

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

And most modern Unix and Unix-like OSs support PAM. If not PAM, then

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []