Description of problem:
Here is how to disable all logins with
pam_loginuid(sshd:session): set_loginuid failed opening loginuid
I noticed this problem in FC5 and it is still present in FC6. It does work in
FC4 (and Debian and Ubuntu). All amd64.
I run SETI-like programs in chroot and under a different userid.
So the command looks like this:
nice -n 10 chroot /var/chroot/blah su boinc sh -c "cd BOINC && ./boinc $args
(First, SELinux has to be off, otherwise it will ask for user "boinc"'s
password, even though you are uid 0 and there is no password for that user, so
this can't work. But that's not the topic of this bug report, I have SE off)
If you do this in FC4 it works fine. If you do it in FC5 or FC6, then something
in PAM breaks and no further login is possible:
~(wavehh)% rl nem
Last login: Mon Oct 30 15:54:56 2006 from wavehh.hanse.de
Connection to nem closed.
Oct 30 15:50:19 nemesis sshd: Postponed publickey for cracauer from
172.16.30.1 port 46785 ssh2
Oct 30 15:50:19 nemesis sshd: Accepted publickey for cracauer from
172.16.30.1 port 46785 ssh2
Oct 30 15:50:19 nemesis sshd: pam_unix(sshd:session): session opened for
user cracauer by (uid=0)
Oct 30 15:50:19 nemesis sshd: pam_loginuid(sshd:session): set_loginuid
failed opening loginuid
Oct 30 15:50:19 nemesis sshd: pam_loginuid(sshd:session): set_loginuid failed
Oct 30 15:50:19 nemesis sshd: error: PAM: pam_open_session(): Cannot
make/remove an entry for the specified session
Version-Release number of selected component (if applicable):
FC6, no patches, no additional programs, no config changes except network,
- create a chroot (I use an AMD64 Debian chroot)
- create user boinc
- as mentioned, SELinux has to be off, or you have to have a password for that user
- excute the above commandline
- afterwards try to ssh into the machine
I can provide the actual chroot that I am using on request.
As mentioned before, it works in FC4, but not FC5 and FC6, although the chroot I
use in all three is precisely the same (rsynced).
From the moment you execute that commandline with chroot and su, PAM will not
allow any further logins. If you are lucky you have a root shell open to reboot
See above for syslog.
PAM should continue to work.
I am happy to prove more info or the actual chroot that I use.
I should clarity this: "~(wavehh)% rl nem"
"rl" is my alias for "ssh", "men" is the FC6 machine affected. This is the
commandline trying to log into the affected machine (just ssh).
I should also mention it doesn't make a difference whether I use an ssh-agent or
direct password entry, and it doesn't matter which userid I try to log in as.
After you execute the commandline above, could you issue
"ls -l /proc/self/loginuid ; cat /proc/self/loginuid ; echo" from another root
What this commandline prints?
Here you go:
~(nemesis)3# sh -c "ls -l /proc/self/loginuid ; cat /proc/self/loginuid ; echo"
-rw-r--r-- 1 root root 0 Oct 31 12:47 /proc/self/loginuid
It is the same number from three different shells currently open.
Can you attach as minimal chroot as possible with which it still happens?
Also does it still happen when you modify the line to:
nice -n 10 chroot /var/chroot/blah su boinc sh -c "cd BOINC && sleep 1000
I can give you a login on that machine if that helps before I can minimize the
chroot. Right now it is 214 MB uncompressed.
Your command line looks truncated, I assume you mean "cd BOINC && sleep 1000
&& ./boinc " at the end.
If you do that, then PAM is already broken during the sleep, before the ./boinc.
OK after trying to diagnose this directly on your machine:
as you wrote to me in a private message the problem is the
mount -r -t proc sdf /var/chroot/sid-amd64-boinc/proc
What happens is that the read only mount of the proc filesystem changes the
/proc mount of the proc filesystem to become read only as well and thus the
pam_loginuid fails. You can get easily back from the broken state with "mount -o
rw,remount -t proc sdf /var/chroot/sid-amd64-boinc/proc". What's much more
strange is that I cannot reproduce this problem on exactly the same kernel on a
different machine. But it is a kernel problem anyway.
[root@nemesis]~# uname -a
Linux nemesis.cons.org 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:39:22 EDT 2006
x86_64 x86_64 x86_64 GNU/Linux
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Seems to be OK with current F8 kernels although the new mounts of proc are just
kept rw although ro mount is requested. But that is probably tolerable.
(In reply to comment #8)
> Seems to be OK with current F8 kernels although the new mounts of proc are just
> kept rw although ro mount is requested. But that is probably tolerable.
The whole point of this is that it should *actually* be readonly. It works fine
on other distributions.
If you have a chroot for security reasons, having a read/write mounted /proc
makes the whole exercise pointless.
Silently converting the requested ro mount to a rw mount, if that is what you
say is happening now, is completely unacceptable.
What kind of info do you need from me specifically?
Actually you're right that the current behavior can have security implications.
What distributions with what kernel versions work fine for you?
(In reply to comment #10)
> Actually you're right that the current behavior can have security implications.
> kernel-18.104.22.168-64.fc8 x86_64
> What distributions with what kernel versions work fine for you?
Debian and Ubuntu, but I use stock (kernel.org) kernels there, so it's really
Overall, I know that this is a result of other security features in Fedora.
However, this effectively disables readonly /proc mounts and hence it makes
chroots useless unless you happen to have applications in there that don't need
/proc at all. That's not the case for many applications you want to cage in. As
I said, most distributed computing projects need this, and my Firefox chroot
needs it, too.
Thanks for the update
We don't change anything intentionally in the Fedora kernel which could affect
mount permissions afaik, so I'm not sure why this would be different.
Could you test a stock kernel on F8 and see if it still happens ? That would
rule out whether it is actually something we apply. Use the same config
options from /boot/config-22.214.171.124-64.fc8 and just run make oldconfig
So, actually trying this I see that the stock kernel now also silently ignores
the fact that the second /proc is mounted readonly.
I'd have to try on an older kernel so see if and when the support for actual
readonly second mounts has been removed.
I think that this behavior switched from the original buggy behavior (silent ro
remount of /proc when proc is mounted somewhere else ro) to the current (silent
rw mount on the secondary mount point). I don't think this ever worked right (at
least in 2.6.x kernels).
Martin, may I ask which threats are you trying to address by read-only proc
mount? Have you managed to get one rw and one ro proc mount on some distro /
Perhaps read-only /proc could work with mount --bind readonly support added in
This behavior seems to be specific only for the /proc filesystem.
Have tried sysfs and tmpfs -- giving "Read-only file system" error
message even on F9 kernel (126.96.36.199-18.fc9.x86_64).
The sysfs case: (188.8.131.52-18.fc9.x86_64)
[root@host dev]# chroot /var/lib/mock/fedora-9-x86_64/root/ mount -t sysfs -r
[root@host dev]# cat
[root@host dev]# echo -e "MAJOR=15\nMINOR=62" >
Read-only file system
The tmpfs case: (184.108.40.206-18.fc9.x86_64)
[root@host dev]# chroot /var/lib/mock/fedora-9-x86_64/root/ umount
[root@host dev]# chroot /var/lib/mock/fedora-9-x86_64/root/ mount -t tmpfs -r
[root@host dev]# touch /var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/hello
touch: cannot touch
`/var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/hello': Read-only file
Seems the /proc filesystem used to behave in the same way till
220.127.116.11-42.fc8. Starting from 2.6.24.*, it silently mounts /proc rw even
when explicit ro mount option is used.
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
Hmm, while F8 is already EOL, this doesn't seem to be fixed in F9 and F10 because there is no fix in upstream yet. Dave/Chuck, take note.
This is definitely not fixed.
Here is a summary of the issue. From memory, some details might be out of focus.
1) when using a chroot for any kind of non-trivial application, including web browsers and seti-at-home type applications you need a /proc, let's say you mount it to /chroot/proc.
2) of course a read-write mounted /chroot/proc will instantly turn security into a joke (as all processes, files and devices are accessible by anybody becoming root in the chroot). But most of these applications, while requiring a /proc, can live with a readonly /proc.
So people like me want two procfs mounts:
- /proc read-write
- /chroot/proc read-only
This is b0rked.
3) the Linux kernel, stock or Redhat, does not support multiple mounts of procfs with different permissions
4) in the mainline kernel, if you have an existing read-write mount to /proc and make a mount request to a read-only /chroot/proc, it will ignore the readonly flag silently and give you a read-write mounted /chroot/proc instead.
5) in redhat/fedora kernels around the time of my initial bug report, and presumably today: given an existing read-write mount to /proc and a mount request to a read-only /chroot/proc, it will downgrade /proc to read-only, effectively disabling the base system.
I think the solution for this must be some kind of "wrapper" filesystem that can put a read-only layer on top of an existing filesystem.
In any case, both behaviors as described in 4) and 5) are unacceptable. Silently giving read-write permissions on a read-only mount request is as wrong as silently downgrading an existing mount.
I strongly urge somebody who is running a recent Fedora to re-open this bug report after confirming which behavior it is showing now. I had cut'n'pasteable reproducing commands in my original bug report and can supply them again.
(In reply to comment #21)
> 2) of course a read-write mounted /chroot/proc will instantly turn security
> into a joke (as all processes, files and devices are accessible by anybody
> becoming root in the chroot). But most of these applications, while requiring
> a /proc, can live with a readonly /proc.
If anybody in the chroot becomes root, she can escape chroot trivially without /proc mounted at all. Read-only vs. read-write /proc mount does not influence that much.
> I strongly urge somebody who is running a recent Fedora to re-open this bug
> report after confirming which behavior it is showing now.
Has this been fixed, or is this test incorrect?
# uname -r
# mkdir -p /chroot/proc
# mount -o ro -t proc proc /chroot/proc/
# cat /proc/mounts | grep '/proc proc'
/proc /proc proc rw 0 0
proc /chroot/proc proc ro 0 0
# echo 1 > /proc/sys/net/ipv4/ip_forward
# echo 1 > /chroot/proc/sys/net/ipv4/ip_forward
bash: /chroot/proc/sys/net/ipv4/ip_forward: Read-only file system
Yes, it seems to be fixed in current kernels. I've tested it with the 2.6.29-0.18.rc0.git9.fc11.x86_64 kernel and it is fixed there too.
(In reply to comment #22)
> (In reply to comment #21)
> > 2) of course a read-write mounted /chroot/proc will instantly turn security
> > into a joke (as all processes, files and devices are accessible by anybody
> > becoming root in the chroot). But most of these applications, while requiring
> > a /proc, can live with a readonly /proc.
> If anybody in the chroot becomes root, she can escape chroot trivially without
> /proc mounted at all. Read-only vs. read-write /proc mount does not influence
> that much.
> > I strongly urge somebody who is running a recent Fedora to re-open this bug
> > report after confirming which behavior it is showing now.
> Has this been fixed, or is this test incorrect?
> # uname -r
> # mkdir -p /chroot/proc
> # mount -o ro -t proc proc /chroot/proc/
> # cat /proc/mounts | grep '/proc proc'
> /proc /proc proc rw 0 0
> proc /chroot/proc proc ro 0 0
> # echo 1 > /proc/sys/net/ipv4/ip_forward
> # echo 1 > /chroot/proc/sys/net/ipv4/ip_forward
> bash: /chroot/proc/sys/net/ipv4/ip_forward: Read-only file system
This looks good.
I don't have FC anymore. My mainline 18.104.22.168 is still broken:
mount -o -ro -t proc proc /mnt/tmp
echo 1 > /mnt/tmp/sys/net/ipv4/ip_forward
# no complaints
Any idea whether this is a 2.6.27 or a Redhat/Fedora fix?