Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mounting in running container #9448

Closed
pyotr777 opened this issue Dec 2, 2014 · 37 comments · Fixed by #9522

Comments

@pyotr777
Copy link

@pyotr777 pyotr777 commented Dec 2, 2014

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

This comment has been minimized.

Copy link
Contributor

@cpuguy83 cpuguy83 commented Dec 2, 2014

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 comment has been minimized.

Copy link
Contributor

@SvenDowideit SvenDowideit commented Dec 3, 2014

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

@pyotr777

This comment has been minimized.

Copy link
Author

@pyotr777 pyotr777 commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Member

@crosbymichael crosbymichael commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Author

@pyotr777 pyotr777 commented Dec 4, 2014

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

This comment has been minimized.

Copy link
Member

@tianon tianon commented Dec 4, 2014

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

@pyotr777

This comment has been minimized.

Copy link
Author

@pyotr777 pyotr777 commented Dec 4, 2014

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

This comment has been minimized.

Copy link
Contributor

@jessfraz jessfraz commented Dec 4, 2014

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

@jessfraz jessfraz closed this Dec 4, 2014
@SvenDowideit

This comment has been minimized.

Copy link
Contributor

@SvenDowideit SvenDowideit commented Dec 4, 2014

reopening as it really needs docs.

@crosbymichael

This comment has been minimized.

Copy link
Member

@crosbymichael crosbymichael commented Dec 4, 2014

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

SvenDowideit pushed a commit to SvenDowideit/docker that referenced this issue Dec 5, 2014
inspired by moby#9448

Docker-DCO-1.1-Signed-off-by: Sven Dowideit <SvenDowideit@docker.com> (github: SvenDowideit)

Signed-off-by: Sven Dowideit <SvenDowideit@docker.com>
SvenDowideit pushed a commit to SvenDowideit/docker that referenced this issue Dec 5, 2014
inspired by moby#9448 and moby#9487

Docker-DCO-1.1-Signed-off-by: Sven Dowideit <SvenDowideit@docker.com> (github: SvenDowideit)

Signed-off-by: Sven Dowideit <SvenDowideit@docker.com>
@fredlf fredlf closed this in #9522 Dec 8, 2014
@thomasyip

This comment has been minimized.

Copy link

@thomasyip thomasyip commented Sep 29, 2015

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

This comment has been minimized.

Copy link
Contributor

@cpuguy83 cpuguy83 commented Sep 30, 2015

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

@thomasyip

This comment has been minimized.

Copy link

@thomasyip thomasyip commented Sep 30, 2015

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

This comment has been minimized.

Copy link

@mattaudesse mattaudesse commented Oct 12, 2015

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

This comment has been minimized.

Copy link
Contributor

@cpuguy83 cpuguy83 commented Oct 12, 2015

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

@hairyhenderson

This comment has been minimized.

Copy link
Contributor

@hairyhenderson hairyhenderson commented Feb 3, 2016

This looks like an issue with some changes made in the apparmor profile.

@cpuguy83 - I'm seeing the same behaviour with boot2docker (1.10-rc1) - I thought b2d didn't use apparmor?

@cpuguy83

This comment has been minimized.

Copy link
Contributor

@cpuguy83 cpuguy83 commented Feb 3, 2016

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

@hairyhenderson

This comment has been minimized.

Copy link
Contributor

@hairyhenderson hairyhenderson commented Feb 3, 2016

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

@cpuguy83

This comment has been minimized.

Copy link
Contributor

@cpuguy83 cpuguy83 commented Feb 3, 2016

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

@hairyhenderson

This comment has been minimized.

Copy link
Contributor

@hairyhenderson hairyhenderson commented Feb 3, 2016

@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

This comment has been minimized.

Copy link
Contributor

@jessfraz jessfraz commented Feb 3, 2016

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

This comment has been minimized.

Copy link
Contributor

@jessfraz jessfraz commented Feb 3, 2016

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

This comment has been minimized.

Copy link
Contributor

@jessfraz jessfraz commented Feb 3, 2016

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

This comment has been minimized.

Copy link
Contributor

@jessfraz jessfraz commented Feb 3, 2016

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

This comment has been minimized.

Copy link
Contributor

@hairyhenderson hairyhenderson commented Feb 3, 2016

@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

This comment has been minimized.

Copy link
Contributor

@hairyhenderson hairyhenderson commented Feb 3, 2016

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

@Rick7C2

This comment has been minimized.

Copy link

@Rick7C2 Rick7C2 commented Apr 24, 2016

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

This comment has been minimized.

Copy link
Member

@thaJeztah thaJeztah commented Apr 24, 2016

@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

This comment has been minimized.

Copy link
Contributor

@jamshid jamshid commented May 24, 2016

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

This comment has been minimized.

Copy link

@sent-hil sent-hil commented May 29, 2016

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

This comment has been minimized.

Copy link

@sarpk sarpk commented Sep 25, 2016

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

This comment has been minimized.

Copy link
Member

@thaJeztah thaJeztah commented Sep 25, 2016

@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

This comment has been minimized.

Copy link

@tobegit3hub tobegit3hub commented Mar 29, 2017

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

@ZongqiangZhang

This comment has been minimized.

Copy link

@ZongqiangZhang ZongqiangZhang commented May 17, 2017

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

aidanhs added a commit to aidanhs/keepassxc that referenced this issue Oct 7, 2017
aidanhs added a commit to aidanhs/keepassxc that referenced this issue Oct 7, 2017
Necessary for an Ubuntu 16.04, Docker 17.09.0-ce host
See moby/moby#9448 (comment)
@manos

This comment has been minimized.

Copy link

@manos manos commented Mar 9, 2018

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

This comment has been minimized.

Copy link

@omeid omeid commented Jul 18, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.