Bug#235804: Re[2]: Bug#235804: gksu: problem with pam_wheel.so trust

[Edward J. Shornock]

Wed, 14 Apr 2004 20:57:00 -0300, Gustavo Noronha Silva wrote:

GNS> Em Qua, 2004-04-14 =E0s 13:18 -0400, Edward J. Shornock escreveu:

>> If pam_wheel.so trust is set for a group, I don't think a user should =
be
>> prompted for the root password (as is currently the case with gksu).  =
So
>> I do have the problem Vinicius had reported as well.  Should I have se=
nt
>> in two separate reports?  (I want to do this the proper way).

GNS> If you have two distinct problems, sure =3D)...

OK, I'll make sure to do this in the future, but as you'll see, these
are not two distinct problems as we thought...

>> I am only prompted for the password by gksu once.  Without the =

>> =22pam_wheel.so trust group=3Dadm=22 line, the gksu helper process con=
tinues
>> as it should.  With that trust line, it should not prompt for the root=

>> password (and I was prompted for it), but in addition to being prompte=
d
>> for the password, gksu-run-helper does not appear to continue.

GNS> Ok, let me try to explain how gksu works:

GNS> gksu spawns a new process and runs gksu-run-helper there, which then=

GNS> sends a message for gksu saying it is ready to receive the password
GNS> and runs su.

This makes sense.

GNS> On receiving that message gksu sends the password to su. So, if I
GNS> understand pam_wheel correctly, gksu-run-helper should acomplish its=

GNS> mission even if you 'cancel' the password dialog (which is a bug, to=
o).

Actually, with this line in /etc/pam.d/su:
          auth       sufficient pam_wheel.so trust group=3Dwheel debug
There should not be a password prompt at all.  When someone in the
group wheel types su, they immediately switch to user root, as the
following shows:
          =5Beshornoc=40darkside:=7E=5D=24 su -
          darkside:=7E=23


GNS> I have to check if I need authorization before asking for the passwo=
rd,
GNS> and I'll have to find a way that takes pam into account. For now, le=
t's
GNS> try to clear this up. Would you make this test for me?:

Of course. :)

GNS> * make su work without a password using pam_wheel

This has been re-enabled, as shown above.

GNS> * run gksu and cancel the dialog

This has been done as well, and I'm sorry I had not done this last
night. It appears that after running gksu as my username (with
pam_wheel.so trust configured, and using the command-line of =22gksu
synaptic=22), I see the following when running =22tail -f
/var/log/auth.log=22:

   Apr 14 20:53:08 darkside PAM-Wheel=5B28984=5D: Access granted to 'esho=
rnoc' for 'root'
   Apr 14 20:53:08 darkside su=5B28984=5D: + pts/135 eshornoc:root

After that entry is logged, the password prompt from gksu is
displayed. The problem is, I've already been granted root's rights,
and synaptic should be run. Output from ps shows:

darkside:=7E=23 ps -fp 30393
UID        PID  PPID  C STIME TTY          TIME CMD
root     30393 30388  0 21:02 pts/137  00:00:00 /usr/lib/gksu/gksu-run-he=
lper synaptic
darkside:=7E=23 ps -fp 30388
UID        PID  PPID  C STIME TTY          TIME CMD
eshornoc 30388 28918  0 21:02 pts/132  00:00:00 gksu synaptic

After hitting the cancel button, the gksu processes terminate.

GNS> Also, I want to know if you're hiting a problem which is totaly
GNS> unrelated to pam_wheel: I've seen gksu be unable to send the passwor=
d to
GNS> su sometimes by trying to do that too soon (you know, su has a delay=
 for
GNS> accepting the password). Maybe you're hiting that problem? In that c=
ase
GNS> you'll have a gksu and su processes running with nothing happening.

No, that's apparently not the problem I'm experiencing. I only have
the output from ps as pasted above (and which follows):

darkside:=7E=23 ps aux =7Cgrep -w gksu=7Cgrep -v grep
eshornoc 30388  7.0  0.6 11176 5744 pts/132  S+   21:06   0:00 gksu synap=
tic
root     30393  0.3  0.0  1904  440 pts/139  Ss+  21:06   0:00 /usr/lib/g=
ksu/gksu-run-helper synaptic
darkside:=7E=23 ps aux =7Cgrep -w su =7Cgrep -v grep
root     18449  0.0  0.1  4832 1684 pts/123  S    10:32   0:00 -su
root     29441  0.0  0.1  4568 1684 pts/122  S    20:57   0:00 -su

So, the problem I reported really *IS* the same as the originally
reported bug, and not a separate issue as it had originally appeared.

GNS> Thanks for your testing and information =3D)

No problem, I'm glad to be able to help make a great distribution of
Linux even better. =3D)