Allow FUSE functionality by default #321
Comments
|
Strongly agree this would be a great feature. It's fairly common to abstract various services via a FUSE driver. If mounting one requires root-like capabilities it encourages lax security. |
|
The kernel requires |
|
@justincormack What about this FUSE Gets User Namespace Support With Linux 4.18 Just a memo below on how it doesn't work currently. Ubuntu 18.04 with stock hwe kernel 4.18.0-18, docker 18.09.5. So atm it doesn't work for
|
|
Someone correct me I am wrong, trying to wrap my head around the limitations here. The user namespace means we could do the current method more securely, perhaps without adding the SYS_ADMIN capabilities, but would still require the fuse device to be passed through. When any mount occurs in a container it is also modifying the host mounts, hence the need for host cooperation. This prevents containers with FUSE from being used on Windows and OSX hosts. If a container's OS was modified to intercept file system calls to emulate it's own FUSE then those FUSE mounts would not be accessible from the host. Is this even possible? |
Fuse mounting inside containers work just fine with Docker for Windows, when passing the same flags: I think the parent poster would want it to just work without any flags? In my opinion the |
Well, as of 4.18, you have |
|
@omeid , what do you meant by 4.18 ? the latest version of blobfuse is 1.0.3 ? which version of blobfuse are you using to run as non root? |
|
@cometta He means this #321 (comment) |
|
+1 on this, requiring SYS_ADMIN is basically a non-starter for us, though the extra device shouldn't be an issue (assuming 4.18+ kernels). Can this get triaged ? |
|
The ability to run fuse without SYS_ADMIN has been enabled for since August, 2018, and yet there hasn't been much traction on this ticket. Running in privilege mode in production should scare most security teams! Is there anything we can do to get more traction on this story? |
|
|
|
I think its all about the linux kernel which need to provide the ability to mount without the sys_admin capability, isn't in the scope of docker |
Checkout this earlier comment, Linux kernel appears to have added namespace support for fuse in |
|
Has anybody actually tried to do this? Something tells me there is much more to this than just allowing mount without CAP_SYS_ADMIN |
|
@cpuguy83 Make sure you have |
|
@omeid That's a debian specific kernel param for enabling (or rather disabling?) userns for unprivileged users, I think? |
|
Debian, Archlinux, too. Check your kernel documentation, and also make sure it is compiled with |
|
@omeid I can create a userns just fine, what I can't do is mount in the userns w/o CAP_SYS_ADMIN. |
|
Any updates on this since? |
|
I need this as well, and giving my containers |
|
The following steps work for me on Fedora 32 to use FUSE in a Docker container without
Depending on the uid mapping Docker uses, this can be considered secure as long as you trust the kernel implementation of unprivileged user namespaces (and FUSE). It would be great if this was supported by default or at least as an easy-to-use alternative profile. Side-note: To allow mounting |
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
In order to run various tests, we need a working /dev/fuse, and this is currently only possible in a privileged container. Github actions workflow doesn't suppport it natively, so we need to initialize a new one ourself, we just keep it running and execute the commands when we need them, not to depend on a static image, so that the github workflow can still be followed as atomic operations. [1] docker/for-linux#321
|
Any progress on this? |
can we possibly get a docker image of this config? |
Is there any security implications doing so ? I want to allow untrusted users to access FUSE for |
@juergbi Thanks to this reply I am 99% of the way to a working set up of using sshfs inside Kubernetes, however I cannot seem to write to the sshfs mount. I have been able to replicate this on my local machine (without using Docker/Kubernetes). Mounting over sshfs works in an unshared shell, but I cannot write to the mount. Using the exact same mounting command outside of the unshared shell gives me write access, so I am sure it is not an issue on the remote server. Any suggestions how to fix this? |
|
any update? |
|
Any progress? |
|
I don't think it's helpful to ping everyone for progress update here, if there is any progress, it will be reported by the ones making progress, in either this issue or a PR (Pull Request). For future readers, please refrain from commenting every week on any updates, as this is inappropriate behavior, this is open source software, if you really want an update, then make it, create a PR fixing the issue, else wait for the update. |
and others
Expected behavior
Mounting FUSE filesystems should work out-of-the box, because it is safe. It fits within the idea of a containerized app.
Actual behavior
An attempt to mount a FUSE filesystem fails with:
fuse: device not found, try 'modprobe fuse' firstor
fuse: failed to exec fusermount: No such file or directoryThe only way to fix it is to run the container with additional permissions:
--cap-add SYS_ADMIN --device /dev/fuseThis makes it very difficult to run FUSE inside Docker because it is often all but impossible to run with additional flags in a managed environment.
Steps to reproduce the behavior
Output of
docker version:The text was updated successfully, but these errors were encountered: