Default sudo setup (Was: Re: The Future of Fedora.)

[Shahms King]

On Wed, 2003-12-10 at 09:38, Michael K. Johnson wrote:
> On Wed, Dec 10, 2003 at 09:07:32AM -0800, Shahms King wrote:
> > I like that scheme and I'm pretty sure it can *all* be done using just
> > sudo and an appropriately clever sudoers file.
> 
> Not quote -- most of this already goes through userhelper, not sudo,
> so from an infrastructure standpoint making /etc/pam.d/ files for
> stuff that uses userhelper use pam_wheel, appropriately configured.
> I just haven't thought through the pam configuration to make the
> "if in wheel, prompt for user password, otherwise prompt for root
> password" scheme work, which is why I thought there might be a bit
> more work to do.
> 
> *Most* of the infrastructure is there, though, I think.
> 
> michaelkjohnson

(My previous problems were, in fact, caused by some maintenance on the
LDAP server so no worries there ;-P)

I don't think the described authentication scheme is possible without
some minor changes to userhelper.  Currently, userhelper can
authenticate either a specific user (usually root) or the '<user>'
invoking it.  That's all well and good, but it doesn't really matter
what you do to the PAM layer underneath, as, essentially, it's
userhelper deciding which user to authenticate as.  So, userhelper needs
to do the wheel check in order to know which password to ask for. 
Unfortunately, pam_xauth breaks with NFS home directories and '<user>'
(it creates a new xauthority file in the home directory which root
cannot read).  This means that any application that uses X will break in
this situation.  I'm guessing it's a 3-line patch to fix xauth, but
anyway.

In order to handle this with "just PAM" a couple of other things are
needed.  First, I don't think userhelper actually uses the prompt
specified by the PAM auth module.  Secondly, there aren't any modules
that allow try_user_pass=<username> or use_user_pass=<username>
(mimicking the {use,try}_first_pass) to attempt to authenticate as a
different user than the one specified.  Or for that matter, attempting
to authenticate as the calling user, rather than the specified user. 
Though I imagine the latter would be relatively easy to add. (Maybe an
additional pam_stack 'user' or 'use_uid' option?)

-- 
Shahms King <shahms at shahms.com>