Mounting in running container

[pyotr777]

Hi!
After capabilities have been introduced, I thought it is now possible to mount external folders (from the host or remote machine with SSHFS) inside running containers without use of --privileged. Am I wrong?

I run Docker 1.3.1 and I cannot mount without --privileged.
Here is a similar issue: #6535

Kind regards,
Peter

[cpuguy83]

Mount requires CAP_SYS_ADMIN, which is not allowed in the default container.
You should be able to do this with "docker run --cap-add SYS_ADMIN

[SvenDowideit]

this comes up often enough that we should add an example to the docs.

[pyotr777]

Thank you for your answers!
I still get error when trying to mount host folder with sshfs.

Inside container started with --cap-add SYS_ADMIN:

root@cf3107829835:/# sshfs user@172.17.42.1:/home/user /mnt
fuse: failed to open /dev/fuse: Operation not permitted

With --privileged it works.

[crosbymichael]

Are you on a system like ubuntu that has apparmor? This could be apparmor blocking the mount, you can look in dmesg and you should see the apparmor blocking this call.

[pyotr777]

My host has Ubuntu 12.04.
I put apparmor docker-default profile into complain mode:

peter@poweredge320:~$ sudo apparmor_status
apparmor module is loaded.
9 profiles are loaded.
8 profiles are in enforce mode.
   /sbin/dhclient
   /usr/bin/lxc-start
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/connman/scripts/dhclient-script
   /usr/sbin/named
   /usr/sbin/ntpd
   /usr/sbin/tcpdump
   lxc-container-default
1 profiles are in complain mode.
   docker-default
3 processes have profiles defined.
2 processes are in enforce mode.
   /usr/sbin/named (1359)
   /usr/sbin/ntpd (1155)
1 processes are in complain mode.
   docker-default (16864)
0 processes are unconfined but have a profile defined.

But still when I start container with --cap-add SYS_ADMIN I cannot use sshfs:

root@e76cafc2dc34:/# sshfs peter@172.17.42.1:/home/peter/ /mnt
fuse: failed to open /dev/fuse: Operation not permitted

In dmesg I see lots of messages like this:

[1950461.070715] type=1400 audit(1417657285.832:282): apparmor="ALLOWED" operation="file_mmap" info="Failed name lookup" error=-13 parent=11128 profile="docker-default" name="var/lib/docker/aufs/diff/5bc37dc2dfba434d7551fa17ee9d3ebba6adab648cebc2f962e612855c4c580c/lib/x86_64-linux-gnu/libdl-2.19.so" pid=17038 comm="bash" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0

When docker-default was in enforce mode, I didn't see docker-related messages in dmesg.

In container started with --privileged I can mount host folders with sshfs.

[tianon]

You should try adding --device /dev/fuse, too.

[pyotr777]

Thank you, Tianon!
Added --device /dev/fuse and voilà:

peter@poweredge320:~$ docker run -ti --cap-add SYS_ADMIN --device /dev/fuse peter/dev:sshfs /bin/bash
root@26cf4dc0a491:/# sshfs peter@172.17.42.1:/home/peter /mnt
peter@172.17.42.1's password:
...

By the way, without --cap-add SYS_ADMIN the error message is different (was "fuse: failed to open /dev/fuse: Operation not permitted" before):

11:36:26peter@poweredge320:~$ docker run -ti --name dev --device /dev/fuse peter/dev:sshfs /bin/bash
root@1d49112eaf95:/# sshfs peter@172.17.42.1:/home/peter/ /mnt
fusermount: mount failed: Permission denied

Thank you all for your help!

The final answer:
Use --cap-add SYS_ADMIN --device /dev/fuse to mount folders with sshfs in container.

[jessfraz]

Going to close this then, glad everything is working :)

[SvenDowideit]

reopening as it really needs docs.

[crosbymichael]

Assigning to @SvenDowideit so hopefully this does not sit open for a long long time.

[thomasyip]

I am using fuse with s3fs.

I used to able to mount with --cap-add SYS_ADMIN --device /dev/fuse alone. But, after updating dependencies (docker, fuse binary, and other), I need to add --privileged. Here the exact options that works for me:

`--privileged --cap-add=MKNOD --cap-add=SYS_ADMIN --device=/dev/fuse`

I think the doc should be updated. (I like to be proved otherwise.)

[cpuguy83]

@thomasyip This looks like an issue with some changes made in the apparmor profile.
See #16429

[thomasyip]

Thank you @cpuguy83 for the info. Indeed, it looks like the issue from docker.

Might still worthy to add a note to the doc. Look like it affects docker since 1.5 and has not been fixed.

[mattaudesse]

Many thanks, @thomasyip (+ others) - I think you saved me a fair amount of legwork with your docker args!

`--privileged --cap-add=MKNOD --cap-add=SYS_ADMIN --device=/dev/fuse`

Those worked great for me.

[cpuguy83]

There is no need for to --cap-add with --privileged.

[cpuguy83]

@hairyhenderson Correct, no apparmor, but now we have a default seccomp profile which blocks mount.

[hairyhenderson]

@cpuguy83 ahh... So is --privileged still the only way to mount stuff?

[cpuguy83]

@hairyhenderson No, but do need to supply a seccomp profile which enables mount.

[hairyhenderson]

@cpuguy83 - ok, thanks! I'm reading https://github.com/docker/docker/blob/master/docs/security/seccomp.md now.

One thing that strikes me as odd is that mount is blocked by the default profile, even though it's already effectively blocked by CAP_SYS_ADMIN...

[jessfraz]

well and you need --cap-add SYS_ADMIN

On Wed, Feb 3, 2016 at 10:44 AM, Brian Goff notifications@github.com
wrote:

@hairyhenderson https://github.com/hairyhenderson No, but do need to
supply a seccomp profile which enables mount.

—
Reply to this email directly or view it on GitHub
#9448 (comment).

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[jessfraz]

and to not be running apparmor, then you are golden

On Wed, Feb 3, 2016 at 10:49 AM, Jessica Frazelle me@jessfraz.com wrote:

well and you need --cap-add SYS_ADMIN

On Wed, Feb 3, 2016 at 10:44 AM, Brian Goff notifications@github.com
wrote:

@hairyhenderson https://github.com/hairyhenderson No, but do need to
supply a seccomp profile which enables mount.

—
Reply to this email directly or view it on GitHub
#9448 (comment).

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu
http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[jessfraz]

we like to have layers of protection :)

On Wed, Feb 3, 2016 at 10:50 AM, Dave Henderson notifications@github.com
wrote:

@cpuguy83 https://github.com/cpuguy83 - ok, thanks! I'm reading
https://github.com/docker/docker/blob/master/docs/security/seccomp.md now.

One thing that strikes me as odd is that mount is blocked by the default
profile, even though it's already effectively blocked by CAP_SYS_ADMIN...

—
Reply to this email directly or view it on GitHub
#9448 (comment).

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[jessfraz]

multiple things like ptrace, are blocked by three layers, its nice to have
those guarantees

On Wed, Feb 3, 2016 at 10:51 AM, Jessica Frazelle me@jessfraz.com wrote:

we like to have layers of protection :)

On Wed, Feb 3, 2016 at 10:50 AM, Dave Henderson notifications@github.com
wrote:

@cpuguy83 https://github.com/cpuguy83 - ok, thanks! I'm reading
https://github.com/docker/docker/blob/master/docs/security/seccomp.md
now.

One thing that strikes me as odd is that mount is blocked by the default
profile, even though it's already effectively blocked by CAP_SYS_ADMIN...

—
Reply to this email directly or view it on GitHub
#9448 (comment).

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu
http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[hairyhenderson]

@jfrazelle - yeah, multiple layers are good I suppose... 😉

I'm having trouble providing a profile:

$ docker run -it --rm --cap-add=mknod --cap-add=sys_admin --device /dev/fuse --security-opt sec comp:`pwd`/my_seccomp_profile.json myimage
Error response from daemon: Cannot start container 45a9c0f53f383f2f42ec345a740a6062aff0c731c9016c5c8546b2fb48533f10: Decoding seccomp profile failed: invalid character '/' looking for beginning of value

[hairyhenderson]

My bad - my client was v1.9.1. When I flipped back to v1.10 it works just fine. Thank you! 😁

[Rick7C2]

Do you happen to know how I can start an already existing container with those flags?
I tried using "docker start container_name --privileged --cap-add=MKNOD --cap-add=SYS_ADMIN --device=/dev/fuse" but I'm unable to use those flags with the start command.
With the docker run command it creates a new container that I then have to re-setup.

[thaJeztah]

@Rick7C2 you can't, you need to start a new container with those options. Depending on your use case, you can start a privileged session in an existing container through docker exec -it --privileged <container> bash

[jamshid]

The comments about seccomp:unconfined above might be out of date. As mentioned in #16429 you need apparmor:unconfined to mount fuse volumes in a container. You should not need to use --privileged.

$ docker run -ti --cap-add SYS_ADMIN --cap-add MKNOD --device=/dev/fuse --security-opt apparmor:unconfined centos bash

[sent-hil]

Was able to get it working with:

docker run -ti --privileged --cap-add SYS_ADMIN --cap-add MKNOD --device=/dev/fuse --security-opt apparmor:unconfined ubuntu-fuse

and

docker exec -ti --privileged <container_id> bash -l

ubuntu-fuse is based off phusion/baseimage-docker

I'm new to Docker so it's possible some of the args are redundant, except --priviledged, it doesn't work without it in docker run. Also followed instructions here, not sure if that's relevant or not.

[sarpk]

Sorry to open this again, is it not possible to add these to Dockerfile so that we can prevent writing each time we are running it?

[thaJeztah]

@sarpk no; a container / image itself should not be able to gain privileges by itself; that would really be dangerous because simply running that image would give it root access to your host; and basically remove all the isolation / security that containers bring. Giving privileges needs to be an explicit action, that you set at runtime (on docker run)

[tobegit3hub]

--cap-add SYS_ADMIN --device=/dev/fuse --security-opt apparmor:unconfined works for me without --privileged in Ubuntu.

[ZongqiangZhang]

docker run -it --cap-add MKNOD --cap-add SYS_ADMIN --device /dev/fuse works for centos 7.0 with Docker 17.05.0-ce

[manos]

Any idea how to do this without the dangerous CAP_SYS_ADMIN?
I've tried explicitly defining a policy, and putting mount/umount/umount2 in the allowed calls, but it still doesn't work unless I --cap-add=SYS_ADMIN. Strace says the mount() call is getting EPERM :(

[omeid]

Being able to use fuse without SYS_ADMIN would be very helpful, this is needed for running AppImages inside docker.

[klzsysy]

--security-opt="seccomp=unconfined" kernel mount
--cap-add=SYS_ADMIN kernel and fuse
--device /dev/fuse fuse mount

use kernel module mount cephfs

[root@mon-mds-mgr-01 ~]# docker run -it --security-opt="seccomp=unconfined"   --cap-add=SYS_ADMIN  --device /dev/fuse registry.xxx.cn/public/centos7-fuse:latest bash
[root@94cb5768fb17 /]# mkdir mount1
[root@94cb5768fb17 /]# mount -t ceph mon-mds-mgr-01:6789,mon-mds-mgr-02:6789,mon-mds-mgr-03:6789:/dir1 -o name=admin,secret=AQCncLpe,fs=fs-002 ./mount1/
failed to load ceph kernel module (1)
[root@94cb5768fb17 /]# df -h
Filesystem                                                Size  Used Avail Use% Mounted on
overlay                                                    36G  7.8G   28G  23% /
tmpfs                                                      64M     0   64M   0% /dev
tmpfs                                                     3.9G     0  3.9G   0% /sys/fs/cgroup
shm                                                        64M     0   64M   0% /dev/shm
/dev/mapper/centos-root                                    36G  7.8G   28G  23% /etc/hosts
tmpfs                                                     3.9G     0  3.9G   0% /proc/acpi
tmpfs                                                     3.9G     0  3.9G   0% /proc/scsi
tmpfs                                                     3.9G     0  3.9G   0% /sys/firmware
10.16.19.21:6789,10.16.19.22:6789,10.16.19.23:6789:/dir1  474G     0  474G   0% /mount1

with fuse mount also is very good