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

[Shahms E. King]

> > Unfortunately, pam_xauth breaks with NFS home directories and '<user>'
> > (it creates a new xauthority file in the home directory which root
> > cannot read).
> 
> Uh, I have used pam_xauth primarily with root-squashed NFS home
> directories; that's how I developed it in the first place.  This
> doesn't make sense to me.  Can you be more explicit about the
> failure mode you have observed?
> 

I don't know the details of what is happening, but from the outside (and
a userhelper-wrapped /bin/env) it appears that pam_xauth uses the file
specified in the calling applications XAUTHORITY environment variable to
create a new .xauth<random chars> file with the appropriate cookies. 
This works just fine when the userhelper USER is "root" because the new
file is created in root's home directory, and then userhelper invokes
the program as root and it can read the file no problem.  But when the
USER is set to '<user>' pam_xauth creates a *new* xauth file in the
user's home directory which would be fine, except userhelper then
invokes the program as root which cannot read this file if it is on a
root-squashed NFS mount.

If you need any more details than that, I'll do what I can.

It seems to me that pam_xauth could easily check and see if the
authenticating user and the calling user are the same to just pass
XAUTHORITY over unmodified? (This obviously breaks in the situation
where the xauth file is in the user's home directory rather than in /tmp
where gdm sticks it when it can't write to the user's home).  That's
probably the wrong way to do it.  I'd imagine the "right" way would
involve not having userhelper authenticate and exec a program as two
different users and moving the <user> functionality into a PAM module. 
That way it's still specifiable on a per-application basis if necessary
and userhelper can be blissfully unaware that the password being entered
is actually for a user other than the one it's going to exec as (other
than the password dialog, of course).

--Shahms
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031210/1cd39b4c/attachment.sig>