podman: Unable to bind mount inside container (mount: mounting on failed: Permission denied)
/kind bug
Description
I require the ability to run mount --bind inside a container.
Steps to reproduce the issue:
sudo podman run -it --privileged docker.io/library/alpine:latest
/ # cd
~ # mkdir tmp
~ # mkdir tmp2
~ # mount --bind tmp tmp2/
mount: mounting tmp on tmp2/ failed: Permission denied
docker run -it --privileged library/alpine:latest
/ # cd
~ # mkdir tmp
~ # mkdir tmp2
~ # mount --bind tmp tmp2/
~ #
Additional information you deem important (e.g. issue happens only occasionally):
$ docker info
Containers: 8
Running: 2
Paused: 0
Stopped: 6
Images: 3505
Server Version: 18.09.5
Storage Driver: btrfs
Build Version: Btrfs v4.19
Library Version: 102
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bb71b10fd8f58240ca47fbb579b9d1028eea7c84
runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
init version: fec3683b971d9c3ef73f284f176672c44b448662
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 5.0.7-gentoo-nulllabs-xeon-apparmor
Operating System: Gentoo/Linux
OSType: linux
Architecture: x86_64
CPUs: 31
Total Memory: 125.9GiB
Name: crucible
ID: LM6K:6A6Y:NATB:6CUG:5YJA:T5YB:JOF5:GGZZ:QNP7:MR5F:QZ5C:55AO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Output of podman version:
Version: 1.2.0
RemoteAPI Version: 1
Go Version: go1.12.1
Git Commit: 3bd528e583182b4249f3e6bbd8497a8831d89950
Built: Fri Apr 12 00:08:57 2019
OS/Arch: linux/amd64
Output of podman info --debug:
debug:
compiler: gc
git commit: 3bd528e583182b4249f3e6bbd8497a8831d89950
go version: go1.12.1
podman version: 1.2.0
host:
BuildahVersion: 1.7.2
Conmon:
package: Unknown
path: /usr/libexec/crio/conmon
version: 'conmon version 1.13.7, commit: 42585737f5eb59273e791e47ab1643e10862d67f'
Distribution:
distribution: gentoo
version: unknown
MemFree: 24831664128
MemTotal: 135142313984
OCIRuntime:
package: Unknown
path: /usr/bin/runc
version: |-
runc version 1.0.0-rc6+dev
commit: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
spec: 1.0.1-dev
SwapFree: 0
SwapTotal: 0
arch: amd64
cpus: 31
hostname: crucible
kernel: 5.0.7-gentoo-nulllabs-xeon-apparmor
os: linux
rootless: false
uptime: 475h 40m 15.31s (Approximately 19.79 days)
insecure registries:
registries:
- crucible.lab:4000
registries:
registries:
- crucible.lab:4000
- docker.io
- registry.fedoraproject.org
- registry.access.redhat.com
store:
ConfigFile: /etc/containers/storage.conf
ContainerStore:
number: 22
GraphDriverName: btrfs
GraphOptions: null
GraphRoot: /var/lib/containers/storage
GraphStatus:
Build Version: 'Btrfs v4.19 '
Library Version: "102"
ImageStore:
number: 15
RunRoot: /var/run/containers/storage
VolumePath: /var/lib/containers/storage/volumes
Additional environment details (AWS, VirtualBox, physical, etc.):
On-prem, self-hosted
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 37 (22 by maintainers)
Commits related to this issue
- apparmor: don't load/set profile in privileged mode Commit 27f9e23a0b9e already prevents setting the profile when creating the spec but we also need to avoid loading and setting the profile when crea... — committed to vrothberg/libpod by vrothberg 5 years ago
- baseline tests: apparmor with --privileged https://github.com/containers/libpod/issues/3112 has revealed a regression in apparmor when running privileged containers where the profile must not be set ... — committed to vrothberg/libpod by vrothberg 5 years ago
- baseline tests: apparmor with --privileged https://github.com/containers/libpod/issues/3112 has revealed a regression in apparmor when running privileged containers where the profile must not be set ... — committed to vrothberg/libpod by vrothberg 5 years ago
- Mock system operations in MountFilesystemsTask task That test previously ran lsblk and mount in the test environment. This does not work in containers [1][2], is meaningless as there are no "real" bl... — committed to martinpitt/anaconda by martinpitt 4 years ago
- Mock system operations in MountFilesystemsTask task That test previously ran lsblk and mount in the test environment. This does not work in containers [1][2], is meaningless as there are no "real" bl... — committed to martinpitt/anaconda by martinpitt 4 years ago
- Mock system operations in MountFilesystemsTask task That test previously ran lsblk and mount in the test environment. This does not work in containers [1][2], is meaningless as there are no "real" bl... — committed to martinpitt/anaconda by martinpitt 4 years ago
- Mock system operations in MountFilesystemsTask task That test previously ran lsblk and mount in the test environment. This does not work in containers [1][2], is meaningless as there are no "real" bl... — committed to martinpitt/anaconda by martinpitt 4 years ago
- Mock system operations in MountFilesystemsTask task That test previously ran lsblk and mount in the test environment. This does not work in containers [1][2], is meaningless as there are no "real" bl... — committed to martinpitt/anaconda by martinpitt 4 years ago
- Mock system operations in MountFilesystemsTask task That test previously ran lsblk and mount in the test environment. This does not work in containers [1][2], is meaningless as there are no "real" bl... — committed to martinpitt/anaconda by martinpitt 4 years ago
- Mock system operations in MountFilesystemsTask task That test previously ran lsblk and mount in the test environment. This does not work in containers [1][2], is meaningless as there are no "real" bl... — committed to martinpitt/anaconda by martinpitt 4 years ago
Once I am back from the trip, I’ll take a look and fire off some VMs with AppArmor on it.
Did you use the —privileged flag?
On Mon 20. May 2019 at 14:54, KBAegis notifications@github.com wrote: