Bug 623522 - bind mounts of /home prevents hardlinks on same file system
Summary: bind mounts of /home prevents hardlinks on same file system
Alias: None
Product: Fedora
Classification: Fedora
Component: pam   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
: 701176 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-12 03:09 UTC by Matt Domsch
Modified: 2011-08-18 00:01 UTC (History)
7 users (show)

Fixed In Version: pam-1.1.3-10.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-06-07 15:38:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Here is the full c file. (12.98 KB, text/x-csrc)
2010-08-25 12:31 UTC, Daniel Walsh
no flags Details

Description Matt Domsch 2010-08-12 03:09:58 UTC
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):
though Dan says it's been around for a long time.

How reproducible:

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:

Comment 1 Daniel Walsh 2010-08-25 12:29:58 UTC
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 $?

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.

Comment 2 Daniel Walsh 2010-08-25 12:30:38 UTC
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) {
			goto err;
		if (fchmod(fd, sb.st_mode | S_ISVTX) < 0) {
			goto err;

	return 0;
	fprintf(stderr, _("Invalid mount point %s: %s\n"), src, strerror(errno));
	return -1;

Comment 3 Daniel Walsh 2010-08-25 12:31:39 UTC
Created attachment 440903 [details]
Here is the full c file.

Comment 4 Daniel Walsh 2010-08-25 12:32:44 UTC
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.

Comment 5 Daniel Walsh 2010-08-25 12:34:17 UTC
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

Comment 6 Bill Nottingham 2010-08-25 16:10:53 UTC
Added where? 'return' doesn't make sense there.

Comment 7 Daniel Walsh 2010-08-25 17:42:58 UTC
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.

Comment 8 Bill Nottingham 2010-08-25 18:02:44 UTC
How early does this need to be done? Is it best in dracut?

Comment 9 Tomas Mraz 2010-08-25 19:35:41 UTC
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.

Comment 10 Tomas Mraz 2011-06-03 12:24:47 UTC
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.

Comment 11 Daniel Walsh 2011-06-03 15:43:34 UTC
Can I modify sandbox init script to remove my mount_private/bind mount changes then?

Comment 12 Tomas Mraz 2011-06-06 06:41:17 UTC
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.

Comment 13 Tomas Mraz 2011-06-07 15:38:31 UTC
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.

Comment 14 Tomas Mraz 2011-06-07 19:49:20 UTC
*** Bug 701176 has been marked as a duplicate of this bug. ***

Comment 15 Jason Haar 2011-06-12 10:53:30 UTC
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

Comment 16 Daniel Walsh 2011-06-13 19:00:24 UTC
chkconfig sandbox off
reboot and your problem will go away.

Comment 17 Jason Haar 2011-06-13 19:21:02 UTC
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

Comment 18 Daniel Walsh 2011-06-14 15:35:31 UTC
Are you sure sandbox is still turned off?  
chkconfig sandbox --list

Comment 19 Jason Haar 2011-06-14 18:34:18 UTC

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

Comment 20 Daniel Walsh 2011-06-14 20:45:16 UTC
Then I have no idea who is bind mounting.  Did you run sandbox?

Comment 21 Jason Haar 2011-06-14 21:06:57 UTC
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)

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
                      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
                     183943268  56387816 118211660  33% /home

Comment 22 Daniel Walsh 2011-06-14 21:11:21 UTC
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@redhat.com.

Comment 23 Tomas Mraz 2011-06-14 22:34:25 UTC
That's not a double mounting of /, it's a completely separate issue.

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