Description of problem: pam_namespace init scripts are not running as root as they did in pam versions < 0.99.8. This severely reduces their usefulness for example when polyinstiating /tmp in the X environment you need to be able to move the X domain socket and this cannot be accomplished as a non-root user. Version-Release number of selected component (if applicable): 1.0.0 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
That's weird and not caused by pam_namespace itself as there is no code which would set the uid in there. This must be caused by the calling application - which is that? And what do you see in the logs?
I'm trying to login through gdm while polyinstiating /tmp but it fails because there is a gdm cookie file written to /tmp. I modified my /tmp init script to copy the cookie file to the polyinstiated instance directory but the cp failed with permission denied so I added an echo of 'id -u -n' to a file and it is my user name and not root. /var/log/secure doesn't have any info related to the execution of the init script and all I see is the session close because gdm fails when it can't find the cookie file.
gdm now sets the real uid to user, but the effective uid should be still 0. Could you strace the login process to find out when the effective uid is changed? As I don't see where the effective uid could be changed in pam I reassign this bug to gdm.
How do I strace gdm?
It is not easy but doable - you have to attach to the gdm-session-worker process when you select the user and the password input box appears before you type the password. Note that the strace will contain the password a few times so do not attach it here as a whole.
I tried to strace gdm here and I see that the real uid!=0 and effective uid==0 when pam_namespace is called, so that should be fine.
So it is pam_namespace that is somehow affecting the euid?
No, it isn't - I simply cannot reproduce the problem here.
Without also having a real uid of 0 it is not possible to mount or do a number of other operations that are required when for example polyinstantiating /tmp in an X environment. As I pointed out in pam < 0.99.10 the init script ran real uid = effective uid = 0. If this can't be the default in the current version can an option for this behaviour be added?
well it's trivial to change the real uid if the effective uid is root, but if the change is causing real breakage we should rethink it I guess.
This would only be necessary during the execution of the pam_namespace init script(s) and the real id could be returned to its original value when the script completed.
Ted: The euid==0 is dropped by shell because the x_namespace.init script (which you sent to me privately) doesn't contain '#!/bin/sh -p' as the first line. mount/unshare/etc... should be possible with euid==0 and ruid!=0 (and it is otherwise pam_namespace wouldn't work at all). Ray: I'm afraid that there could happen more breakages due to the change in gdm. I don't know if other login services set the ruid to user before pam_setcred/pam_open_session. Modules which I own (from pam package) do not expect/require it to be set. I don't know whether other modules have different requirements though.
okay, i'll change it today.
It will also solve the symptoms of the bug 431535
(In reply to comment #12) > Ted: > The euid==0 is dropped by shell because the x_namespace.init script (which you > sent to me privately) doesn't contain '#!/bin/sh -p' as the first line. > > mount/unshare/etc... should be possible with euid==0 and ruid!=0 (and it is > otherwise pam_namespace wouldn't work at all). I looked at the mount source and verified that it is not possible to use and arguments or options with the mount when euid != ruid. > > Ray: > I'm afraid that there could happen more breakages due to the change in gdm. I > don't know if other login services set the ruid to user before > pam_setcred/pam_open_session. Modules which I own (from pam package) do not > expect/require it to be set. I don't know whether other modules have different > requirements though. >
(In reply to comment #15) > I looked at the mount source and verified that it is not possible to use and > arguments or options with the mount when euid != ruid. I meant mount(2) syscall not mount(8) command-line utility.
(In reply to comment #12) > Ted: > The euid==0 is dropped by shell because the x_namespace.init script (which you > sent to me privately) doesn't contain '#!/bin/sh -p' as the first line. > Thanks, I learned something new. I'd never used the -p option before and didn't know it existed but it seems to have resolved the issue. I'll do some more testing just to be sure. > mount/unshare/etc... should be possible with euid==0 and ruid!=0 (and it is > otherwise pam_namespace wouldn't work at all). > > Ray: > I'm afraid that there could happen more breakages due to the change in gdm. I > don't know if other login services set the ruid to user before > pam_setcred/pam_open_session. Modules which I own (from pam package) do not > expect/require it to be set. I don't know whether other modules have different > requirements though. >
this should be fixed in gdm-2.21.10-0.2008.04.11.2.fc9