Description of problem: Because /home is bind-mounted over the top of itself, you cannot cp -l or mv a file from /home to somewhere else in / (when /home and / are on the same file system) without the command failing or copying instead of moving, respectively. Version-Release number of selected component (if applicable): policycoreutils-2.0.82-13.fc13.i686 though Dan says it's been around for a long time. How reproducible: always Steps to Reproduce: 1. create file on /home 2. sudo cp -l /home/file /somewhere 3. see cp -l fail because /home and / are on different file systems, but they're not really. Actual results: cp -l fail, or mv does a copy-then-delete. Expected results: cp -l succeeds; mv does not copy-then-delete. Additional info:
I woke up this morning with an epiphany. We can eliminate the mount command by moving it into pam_namespace. The current script does the following at boot mount --make-rshared / || return $? mount --rbind /tmp /tmp || return $? mount --rbind /var/tmp /var/tmp || return $? mount --make-private /tmp || return $? mount --make-private /var/tmp || return $? for h in $HOMEDIRS; do mount --rbind $h $h || return $? mount --make-private $h || return $? done But the only line we really need is --make-rshared / || return $? We can do the bind mounts and make-privates in pam_namespace. This is what I am now doing in sadbox/seunshare.
Here is the function I am using in F14. static int seunshare_mount(const char *src, const char *dst, struct passwd *pwd) { if (verbose) printf("Mount %s on %s\n", src, dst); int flags = MS_REC; if (strcmp("/tmp", dst) == 0) { flags = flags | MS_NODEV | MS_NOSUID | MS_NOEXEC; } if (mount(dst, dst, NULL, MS_BIND | flags, NULL) < 0) { fprintf(stderr, _("Failed to mount %s on %s: %s\n"), dst, dst, strerror(errno)); return -1; } if (mount(dst, dst, NULL, MS_PRIVATE | flags, NULL) < 0) { fprintf(stderr, _("Failed to make %s private: %s\n"), dst, strerror(errno)); return -1; } if (mount(src, dst, NULL, MS_BIND | flags, NULL) < 0) { fprintf(stderr, _("Failed to mount %s on %s: %s\n"), src, dst, strerror(errno)); return -1; } if (verify_mount(dst, pwd) < 0) return -1; if (strcmp("/tmp", dst) == 0) { struct stat sb; int fd = open(dst,O_RDONLY); if ( fd == -1 ) goto err; if (fstat(fd, &sb) == -1) { close(fd); goto err; } if (fchmod(fd, sb.st_mode | S_ISVTX) < 0) { close(fd); goto err; } close(fd); } return 0; err: fprintf(stderr, _("Invalid mount point %s: %s\n"), src, strerror(errno)); return -1; }
Created attachment 440903 [details] Here is the full c file.
Changing to this method also allows greater flexibility since you do not know what file system is going to be mounting in pam_namespace, it readds the sticky bit to the /tmp file system which could cause problems.
If pam_namespace gets this fix, I will remove the code from the sandbox init script and try to get the mount --make-rshared / || return $? line added to /etc/rc.sysinit
Added where? 'return' doesn't make sense there.
I meant mount --make-rshared / After / is mounted. This command allows xguest or sandboxes processes to mounts added to the / file system. But not changes to their view of /home or /tmp.
How early does this need to be done? Is it best in dracut?
I think that before any user sessions should be sufficient. The question is whether services such as various daemons which run under non-root account should not be able to utilize per-user mounts of /tmp and similar too. Which would mean to run it before any of these services.
I've added a patch to rawhide PAM (pam-1.1.3-9.fc16) so that if pam_namespace is called with option 'mount_private' it will call the necessary mount() calls to make the polyinstantiated directory mounts private. The patch is in upstream GIT repository as well. Now we need to change the PAM config files to use the mount_private option.
Can I modify sandbox init script to remove my mount_private/bind mount changes then?
We would need to modify all the PAM config files that contain pam_namespace before that. I'm still trying to find some reasonably reliable way to detect that we need to call the private mount so the mount_private option does not have to be added.
I've added a simple autodetection of the / shared mount (from /proc/self/mountinfo) and enabling the mount_private automatically based on that. The remaining question is whether we want this in Fedora 15. If so, we should make update together with the sandbox.
*** Bug 701176 has been marked as a duplicate of this bug. ***
As my 701176 was added as a dupe of this, I'll add a followup to this one instead I am still seeing both "/" and "/home" double-mounted on my 100% up-to-date system, and I just rebooted and got inode errors on the way down. I had to power it off (this is due to another bug that stops any kernel I've had since F15beta2 was released for rebooting!) and on the way back up it totally crapped itself and I ended up in single-user mode with a corrupt filesystem. A fsck actually fixed it and now it's seems fine. However, as this system reports that it cannot umount at shutdown (this bug?), and fails to shutdown (704894), I think fs corruption is sort of an obvious eventual outcome? Are you sure this is the same bug? The conversation in this ticket seems to imply this "double mounting" is expected behaviour, whereas what I'm seeing smells like a bug? This disk was encrypted during install if that makes a difference
chkconfig sandbox off reboot and your problem will go away.
That's no longer true. I did that back when ticket 701176/Comment 11 suggested it and indeed it worked - no more double-mounts. But 2 days ago I did a reboot, it failed to shutdown (I have another bug report in on that - this laptop has NEVER been able to shutdown cleanly with F15) and when I forced it (after waiting 5 minutes) it came up with a corrupt enough filesystem that I had to manually fsck it! Then I noticed my double-mounts were back - even though sandbox is marked as off. So some time since 9/May some package update has changed something and re-introduced the double-mounting problem irrespective of the state of sandbox I have to reboot this laptop every couple of days due to a video card problem [sigh, I want F13 back :-(], so it could be that the "something" happened a week or more ago
Are you sure sandbox is still turned off? chkconfig sandbox --list
yes chkconfig sandbox --list Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. sandbox 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Then I have no idea who is bind mounting. Did you run sandbox?
You mean did I manually start the service? No. In fact I have never been able to successfully use SElinux (due to it breaking every 2nd package I try to install), so the first thing I do with my new systems is disable it - so the last thing I'd want to start would be SElinux-related services. However, this double-mounting problem I now have is different than what I had before I disabled sandbox - so I think you're right and something else is doing it. Now I don't see /home double-mounted - only "/" (I think the cgroup mount is due to kvm which I now have running) df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 51606140 44962996 6119044 89% / udev 4024520 0 4024520 0% /dev tmpfs 4066888 4300 4062588 1% /dev/shm tmpfs 4066888 876 4066012 1% /run /dev/mapper/vg_tnzjhaardell-lv_root 51606140 44962996 6119044 89% / tmpfs 4066888 0 4066888 0% /sys/fs/cgroup tmpfs 4066888 0 4066888 0% /media /dev/sda1 495844 74377 395867 16% /boot /dev/mapper/vg_tnzjhaardell-lv_home 183943268 56387816 118211660 33% /home
Ok, If you are not running SElinux you probably could remove policycoreutils-sandbox. I would like to know which packages you have recently installed that caused SELinux problems, but this bugzilla is not the place to carry that conversation, if you want to send me more info, please mail to dwalsh.
That's not a double mounting of /, it's a completely separate issue.