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. /var/log/secure says: Oct 30 15:50:19 nemesis sshd[2905]: Postponed publickey for cracauer from 172.16.30.1 port 46785 ssh2 Oct 30 15:50:19 nemesis sshd[2904]: Accepted publickey for cracauer from 172.16.30.1 port 46785 ssh2 Oct 30 15:50:19 nemesis sshd[2906]: pam_unix(sshd:session): session opened for user cracauer by (uid=0) Oct 30 15:50:19 nemesis sshd[2906]: pam_loginuid(sshd:session): set_loginuid failed opening loginuid Oct 30 15:50:19 nemesis sshd[2906]: pam_loginuid(sshd:session): set_loginuid failed Oct 30 15:50:19 nemesis sshd[2906]: 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, SELinux off. How reproducible: - 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). Actual results: 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 soft. See above for syslog. Expected results: PAM should continue to work. Additional info: 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 shell? 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 4294967295 ~(nemesis)4# 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. http://fedoraproject.org/wiki/LifeCycle/EOL 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 the change. 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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. kernel-2.6.24.4-64.fc8 x86_64 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-2.6.24.4-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 not distribution-specific. 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 Martin
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-2.6.24.4-64.fc8 and just run make oldconfig Thanks.
Weeeeell... 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 / kernel?
Perhaps read-only /proc could work with mount --bind readonly support added in 2.6.26-rc?
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 (2.6.25.3-18.fc9.x86_64). The sysfs case: (2.6.25.3-18.fc9.x86_64) [root@host dev]# chroot /var/lib/mock/fedora-9-x86_64/root/ mount -t sysfs -r sys home/boinc/fakeext3 [root@host dev]# cat /var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/class/misc/network_latency/uevent MAJOR=10 MINOR=62 [root@host dev]# echo -e "MAJOR=15\nMINOR=62" > /var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/class/misc/network_latency/uevent -bash: /var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/class/misc/network_latency/uevent: Read-only file system The tmpfs case: (2.6.25.3-18.fc9.x86_64) [root@host dev]# chroot /var/lib/mock/fedora-9-x86_64/root/ umount home/boinc/fakeext3 [root@host dev]# chroot /var/lib/mock/fedora-9-x86_64/root/ mount -t tmpfs -r tmp home/boinc/fakeext3 [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 system Seems the /proc filesystem used to behave in the same way till 2.6.23.1-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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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 2.6.27.9-159.fc10.x86_64 # 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 > 2.6.27.9-159.fc10.x86_64 > > # 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 2.6.26.3 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? Thanks Martin