Bug 504890

Summary:	mount --make-private and friend are broken in some cases
Product:	Red Hat Enterprise Linux 6	Reporter:	Alexander Viro <aviro>
Component:	util-linux-ng	Assignee:	Karel Zak <kzak>
Status:	CLOSED UPSTREAM	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.0	CC:	aviro, dwalsh
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-01-29 14:40:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexander Viro 2009-06-09 22:42:03 UTC

mount(8) knows not to expect fs type with --bind and --move, but for --make-private et.al. it tries to guess fs type by "device name" (in reality - mountpoint) and if libblkid comes up with something that has /sbin/mount.foo helper, that helper gets called.  As the result, we get hell knows what mounted on the mountpoint, instead of propagation flag change we'd been expecting.

Happens e.g. if you have tmpfs mounted on /tmp and try to say mount --make-private /tmp.  If there's mount.tmpfs, you'll get new instance of tmpfs mounted on top /tmp, instead of the expected behaviour.

Fixed in util-linux-ng.git by commit c4966ccb16868fa748009a826340fac9d1b1ce (adds MS_PROPAGATION to the existing check for no-fstype-involved flags)

Comment 1 Karel Zak 2009-06-10 08:02:16 UTC

(In reply to comment #0)
> Fixed in util-linux-ng.git by commit c4966ccb16868fa748009a826340fac9d1b1ce
> (adds MS_PROPAGATION to the existing check for no-fstype-involved flags) 

Unfortunately, this patch is not enough. This morning I had more time to reproduce the problem and I found that we also call check_special_mountprog() (it means exec(/sbin/mount.<type>)) before guess_fstype_and_mount().

The problem should be properly fixed by commit 0fae284a7a13d4d2dba7a908e0662a6d9c46f877 in util-linux-ng.git.

Comment 2 RHEL Program Management 2009-06-15 20:56:39 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Karel Zak 2010-01-29 14:40:31 UTC

already fixed in RHEL6