mounting a fs in two places at once?

I just installed redhat 7.1 on a system.

Cleaning up, a made a fs for home...(mounted on /mnt to write the stuff to it)

Then I accidently mounted it on /home.

So it was mounted on /home and /mnt at the same time.
(I didn't bother going in to see what was there).
Shouldn't this NOT happen?
[root@pb /]# mount
/dev/hda9 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hda5 on /boot type ext2 (rw)
/dev/hda7 on /usr type ext2 (rw)
/dev/hda6 on /var type ext2 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
automount(pid603) on /misc type autofs (rw,fd=5,pgrp=603,minproto=2,maxproto=3) pb:(pid704) on /net type nfs (intr,rw,port=1023,timeo=8,retrans=110,indirect,ma p=/etc/amd.net,dev=00000007)
/dev/hda10 on /mnt type ext2 (rw)
/dev/hda10 on /home type ext2 (rw)

Is this a feature or a bug?

This is with 2.4.2...

Marty Leisner
[email protected]

Same tree, obviously.

Sigh... Guys, who maintains l-k FAQ?

Q: I've mounted filesystem in two different places and it worked. Why?
A: Because you've asked to do that. Yes, it works. No, it's not a bug.

Q: what should I do to unmount it?
A: umount <mountpoint>

Q: but that took care only of one of them. How can I deal with another?
A: umount <another_mountpoint>

You mean the LK mailing list FAQ? That would be me.

Patches to the LKML FAQ accepted :-)

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

feature.

Jeff

Feature. It actually makes it quite nice when you want to allow chrooted user(s) access to a common directory, you just mount a partition in all the users home dirs.

-b

:    __o
:   -\<,
:   0/ 0
-----------

For security, this can be a bad idea.

Potentially, chrooted user can mess with another, by messing with libraries and such like. In most cases not terribly easy, but in some cases possible.

No, if the fs was mounted RO, then I assume you would have less to worry about. Its a pity the VFS code doesn't allow you to fix RO & RW of the same fs.

--cw

If chrooted user had gained root - he can do much more damage than that. If your libraries are world-writable - you had asked for that, hadn't you?

<shrug> 2.5 stuff. Requires extra argument on getattr/setattr/permission - prototype change on 3 methods for something that is a feature and not a fix for any specific bug...

If you want root-proof analog of chroot - fine, but that will require at least taking away the ability to mount/umount anything. Otherwise attacker will simply be able to remount everything he want r/w once he had gained root. That can be done (e.g. by adding "can modify" flag to namespace and doing something along the lines

	pid = clone(CLONE_NAMESPACE, NULL);
	if (!pid) {
		/* do all needed mount/umount work */
		pid = clone(CLONE_FREEZE_NAMESPACE, NULL);
		if (!pid) {
			/* we are set */
		}
		exit(0);
	}

which would give grandchild a namespace we want it to see and prohibit any changes in said namespace, root or not)

How does FreeBSD implement this with jails? Don't jailed people get dummy /dev access that is more or less crippled?

I wonder if all this effort is really worth it though, it seems like lots of 'fixes' to avoid the all-powerful root, so perhaps the fix lies elsewhere?

--cw

'tis very true.

I have been using this for FTP users, such as allowing a common /mp3 download directory relative to each users jail. That is what I was referring to, should have been more specific.

-b

:    __o
:   -\<,
:   0/ 0
-----------