10

I use mount -o bind to mount directories inside chroots, which works really well. The problem is that I'd like some of these bind-mounted directories to be read only in chroot.

Is it possible? If not - any other way to achieve it?

I was thinking about using NFS for localhost mounts, but it looks like overkill.

4 Answers4

17

Direct answer from the LWN article:

mount --bind /vital_writable_data /untrusted_container/vital_data
mount -o bind,remount,ro /untrusted_container/vital_data

Supported since Linux 2.6.26.

Community
  • 1
blueyed
  • 723
  • 8
  • 13
10

According to this article is it is possible. You do need a recent kernel.

mount --bind -o ro /vital_data /untrusted_container/vital_data
sanmai
  • 521
  • 5
  • 19
Zoredache
  • 128,755
  • 40
  • 271
  • 413
4

In Squeeze it used to work with only:

mount --bind /src /dst

then

mount -o remount,ro /dst

Now in Debian Wheezy you have to do:

mount -o remount,ro,bind /dst

to get rid of the: resource busy message.

Edit: Now in Debian Jessie, mount tries to be smart and mounts sub dirs, which if already mounted with bind, gets recursive and bad things happens :)

There is a special option that forces util-linux to be 'stupid' again. Solutions is this:

mount --bind --make-rprivate /sbin/ $prefix/sbin/
mount -o remount,ro,bind $prefix/sbin/

Afterwards you can mount --bind $prefix/sbin to another dir.

From the man page:

The shared subtree operations. Since Linux 2.6.15 it is possible to mark a mount and its submounts as shared, private, slave or unbindable. A shared mount provides the ability to create mirrors of that mount such that mounts and unmounts within any of the mirrors propagate to the other mirror. A slave mount receives propagation from its master, but not vice versa. A private mount carries no propagation abilities. An unbindable mount is a private mount which cannot be cloned through a bind operation. The detailed semantics are documented in Documentation/filesystems/sharedsubtree.txt file in the kernel source tree. Supported operations are: 

     mount --make-shared mountpoint
     mount --make-slave mountpoint
     mount --make-private mountpoint
     mount --make-unbindable mountpoint

The following commands allow one to recursively change the type of all the mounts under a given mountpoint.

     mount --make-rshared mountpoint
     mount --make-rslave mountpoint
     mount --make-rprivate mountpoint
     mount --make-runbindable mountpoint

mount(8) does not read fstab(5) when a --make-* operation is requested. All necessary information has to be specified on the command line. Note that the Linux kernel does not allow to change multiple propagation flags with a single mount(2) syscall, and the flags cannot be mixed with other mount options.

Since util-linux 2.23 the mount command allows to use several propagation flags together and also together with other mount operations. This feature is EXPERIMENTAL. The propagation flags are applied by additional mount(2) syscalls when the preceeding mount operations were successful. Note that this use case is not atomic. It is possible to specify the propagation flags in fstab(5) as mount options (private, slave, shared, unbindable, rprivate, rslave, rshared, runbindable).

Anton Valqk
  • 231
  • 2
  • 3
2

mount --bind /vital_data /untrusted_container/vital_data

mount -o remount,ro,bind /untrusted_container/vital_data

in the second mount you have to use "remount,ro,bind" otherwise all other instances of /vital_data will got read-only right too.

Community
  • 1
rexo
  • 21
  • 2
  • No, you don't (at least not on Linux 3.19). Where did you experience the necessity of adding the `bind` option? – Kalle Richter Feb 12 '15 at 07:14
  • 1
    @KarlRichter - I have not tested it, but `man 2 mount` indicates that `bind` is required: "Since Linux 2.6.26, the `MS_REMOUNT` flag can be used with `MS_BIND` to modify only the per-mount-point flags. This is particularly useful for setting or clearing the "read-only" flag on a mount point without changing the underlying filesystem. Specifying mountflags as: `MS_REMOUNT | MS_BIND | MS_RDONLY` will make access through this mountpoint read-only, without affecting other mount points." (From Ubuntu 19.10, Linux `man-pages` release 5.0.2, dated 2019-08-02.) – mpb Apr 21 '20 at 05:09
  • 1
    @KarlRichter - Update: According to https://unix.stackexchange.com/a/128388, newer versions of `libmount` call the `mount()` function twice during a single invocation of the `/usr/bin/mount` program. So it is the version of `libmount`, rather than the kernel version, that will determine whether or not two invocations of `/usr/bin/mount` are needed. – mpb Apr 22 '20 at 19:06