Bug 441684 - pam_namespace iscript not running as root
pam_namespace iscript not running as root
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-09 10:17 EDT by Ted X Toth
Modified: 2015-01-14 18:20 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-11 17:04:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ted X Toth 2008-04-09 10:17:41 EDT
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:
Comment 1 Tomas Mraz 2008-04-09 10:31:25 EDT
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?
Comment 2 Ted X Toth 2008-04-09 11:14:31 EDT
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. 
Comment 3 Tomas Mraz 2008-04-09 11:49:09 EDT
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.
Comment 4 Ted X Toth 2008-04-10 08:56:37 EDT
How do I strace gdm? 
Comment 5 Tomas Mraz 2008-04-10 09:42:04 EDT
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.
Comment 6 Tomas Mraz 2008-04-10 09:43:16 EDT
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.
Comment 7 Ted X Toth 2008-04-10 09:58:02 EDT
So it is pam_namespace that is somehow affecting the euid?
Comment 8 Tomas Mraz 2008-04-10 11:46:50 EDT
No, it isn't - I simply cannot reproduce the problem here.
Comment 9 Ted X Toth 2008-04-10 14:50:09 EDT
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?
Comment 10 Ray Strode [halfline] 2008-04-10 15:51:45 EDT
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.
Comment 11 Ted X Toth 2008-04-10 16:06:26 EDT
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.
Comment 12 Tomas Mraz 2008-04-11 03:00:14 EDT
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.
Comment 13 Ray Strode [halfline] 2008-04-11 09:06:53 EDT
okay, i'll change it today.
Comment 14 Tomas Mraz 2008-04-11 09:17:41 EDT
It will also solve the symptoms of the bug 431535
Comment 15 Ted X Toth 2008-04-11 09:44:53 EDT
(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.
> 

Comment 16 Tomas Mraz 2008-04-11 09:59:15 EDT
(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.
Comment 17 Ted X Toth 2008-04-11 10:43:09 EDT
(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.
> 

Comment 18 Ray Strode [halfline] 2008-04-11 17:04:06 EDT
this should be fixed in gdm-2.21.10-0.2008.04.11.2.fc9

Note You need to log in before you can comment on or make changes to this bug.