remounts don't work with mountall

Bug #519380 reported by Stephane Chazelas on 2010-02-09
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: mountall

Hi,

the context:

to have the noexec or nosuid applied on a --bind mount, you need to do it in two steps (one may argue that mount(8) is broken in that way):

mount --bind /here /there
mount -o remount,noexec /there

(mount --bind -o noexec /here /there won't work).

So, in /etc/fstab, you've got to write it:

/here /there none bind 0 0
remount-there /there none remount,noexec 0 0

However the above doesn't work with mountall.

It does work with "mount -a" so it seems it's a regression from pre-mountall ubuntu releases.

The problem occurs both on karmic and lucid (2.4):

Johan Kiviniemi (ion) wrote :

It seems to me the correct fstab entry would look like

/here /there none bind,noexec

mount needs to be modified to handle that, though.

There’s also a race condition in mounting something without noexec and then adding the flag with remount. A mount that needs to be noexec for whatever reason isn’t for a short period.

Not that it’s likely to cause a problem, but that’s an indicator something’s not right with the method.

2010-02-09 18:02:32 -0000, Johan Kiviniemi:
> It seems to me the correct fstab entry would look like
>
> /here /there none bind,noexec
>
> mount needs to be modified to handle that, though.

Yes, agreed, see:

http://article.gmane.org/gmane.linux.utilities.util-linux-ng/2979

raised today.

> There’s also a race condition in mounting something without noexec and
> then adding the flag with remount.

Yes, though you'd had the same condition (though shorter) if
mount(8) were modified as you need 2 mount(2) system calls
anywat.

> A mount that needs to be noexec for
> whatever reason isn’t for a short period.

Yes, but here we're talking of /etc/fstab which (unless noauto
is also passed, which is not really our concern here as we're
discussing mountall), this is gonna happen before anybody can
log in and exploit the race condition.

In my case, I'm actually doing a mount --bind /here /here and
I'm concerned with suid files. /here contains file systems
trees meant to be mounted as root file systems by other hosts
over NFS, I want local users to be able to access the images for
reading, but I don't want suid files as they could potentially
be exploited .

> Not that it’s likely to cause a problem, but that’s an indicator
> something’s not right with the method.

I agree, but at the moment, I didn't have any way around that
(other than adding an init script that mounts those separately),
and it used to work, so it's a regression.

I've now found not too bad a work around: have a
/sbin/mount.bind like:

#! /bin/sh -x
[ "$#" -ge 2 ] || exit
dev=$1 mount_point=$2; shift 2
/bin/mount -i --bind -- "$dev" "$mount_point" || exit
[ "$1" != "-o" ] && exit
exec /bin/mount -i -o remount "$@" "$mount_point"

and then:

/here /there bind noexec 0 0

in fstab

Of, course /sbin/mount.bind being a shell script, you don't want
to add the "user" option to the script, but that script could be
written in a safer language, you get the idea.

--
Stephane

2010-02-09 20:37:34 -0000, Stephane Chazelas:
[...]
> I've now found not too bad a work around: have a
> /sbin/mount.bind like:
>
> #! /bin/sh -x
> [ "$#" -ge 2 ] || exit
> dev=$1 mount_point=$2; shift 2
> /bin/mount -i --bind -- "$dev" "$mount_point" || exit
> [ "$1" != "-o" ] && exit
> exec /bin/mount -i -o remount "$@" "$mount_point"
>
> and then:
>
> /here /there bind noexec 0 0
>
> in fstab
>
> Of, course /sbin/mount.bind being a shell script, you don't want
> to add the "user" option to the script, but that script could be
> written in a safer language, you get the idea.
[...]

Please ignore that last part, that script is run as the real
user (I had assumed it was run as root because of mount's
setuid). And "user" mounts wouldn't work anyway here. I can see
mount.smbfs is a shell script as well.

regards,
Stephane

Changed in mountall (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers