Skip to content
This repository has been archived by the owner on May 6, 2020. It is now read-only.

mount: permission denied, after "docker run --device=/dev/xx:/dev/xx" #927

Closed
ddongchen opened this issue Jan 16, 2018 · 6 comments
Closed

Comments

@ddongchen
Copy link

Description of problem

 I created the test.img and associated with a loop device following the Block Device example from "https://github.com/clearcontainers/runtime/blob/master/docs/Passing-Devices-with-Clear-Containers.md"". then run "docker run -d --device /dev/loop2:/dev/sdc xxx".
The container started successfully, then i exec the container, and run "mount /dev/sdc /mnt", encountering the err "mount: permission denied".
I also run "docker run -d --device /dev/loop2:/dev/sdc --cap-add=SYS_ADMIN --security-opt seccomp:unconfined xxx", the same error msg.

[xxxx]# cc-runtime cc-env
[Meta]
Version = "1.0.6"

[Runtime]
Debug = false
[Runtime.Version]
Semver = "3.0.12"
Commit = "be7d1cebb5e8afbb2a9329264d4163adc70b0362-dirty"
OCI = "1.0.0-dev"
[Runtime.Config]
Path = "/usr/share/defaults/clear-containers/configuration.toml"

[Hypervisor]
MachineType = "pc"
Version = "QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers"
Path = "/usr/local/bin/qemu-system-x86_64"
Debug = false

[Image]
Path = "/usr/share/clear-containers/clear-19790-containers.img"

[Kernel]
Path = "/usr/share/clear-containers/vmlinuz-4.9.60-82.1.container"
Parameters = ""

[Proxy]
Type = "ccProxy"
Version = "Version: 3.0.12+git.3c6daa6"
Path = "/usr/libexec/clear-containers/cc-proxy"
Debug = true

[Shim]
Type = "ccShim"
Version = "shim version: 3.0.12 (commit: d01f9a7)"
Path = "/usr/libexec/clear-containers/cc-shim"
Debug = true

[Agent]
Type = "hyperstart"
Version = "<>"

[Host]
Kernel = "3.10.0-327.22.2.el7.x86_64"
CCCapable = true
[Host.Distro]
Name = "CentOS Linux"
Version = "7"
[Host.CPU]
Vendor = "GenuineIntel"
Model = "Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz"

[xxx]# docker --version
Docker version 17.09.1-ce, build 19e2cf6

[xxx]# uname -a
Linux docker-10-22-123-60 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

(replace this text with the list of steps you followed)

Expected result

(replace this text with an explanation of what you thought would happen)

Actual result

(replace this text with details of what actually happened)


(replace this text with the output of the cc-collect-data.sh script, after you have
reviewed its content to ensure it does not contain any private information).

@grahamwhaley
Copy link
Contributor

/cc @egernst @amshinde
I have a feeling this mount inside the container will no longer work as we have tightened up the container security wrt 'capabilities' to match the software containers defaults. I think the doc will need updating to give some details of how to now get the device mounted - but I'll let those with more hands on info update that (and this Issue).
Thanks for raising it!
Oh, and here is the link pulled out from the block text, for 'easy clicking' :-)
https://github.com/clearcontainers/runtime/blob/master/docs/Passing-Devices-with-Clear-Containers.md

@ddongchen
Copy link
Author

@grahamwhaley Thanks for the quick response, and waiting for the details!

@egernst
Copy link

egernst commented Jan 16, 2018

@grahamwhaley -- there are a few things 'broken' by the CAPs being added and not having a way to provide non-default / privileged capabilities. Archana has a PR underway to address being able to modify these capabilities.

I wonder, what's the behavior on runc for this? We should match, regardless of caps.

@amshinde
Copy link
Contributor

@egernst @grahamwhaley Our current capabilities inside a container are the same as the default restricted set of capabilities in runc. In order to be able to perform mounts, one would need to start the container as docker run --cap-add SYS_ADMIN.

There are 2 PR's that need to be merged for the -cap-add to work:
clearcontainers/proxy#196
clearcontainers/agent#188

But I am seeing some CI issues on them, not related to the PR.

@devimc
Copy link

devimc commented Feb 15, 2018

@ddongchen clearcontainers/proxy#196 and clearcontainers/agent#188 were merged, could you please check again ?

@ddongchen
Copy link
Author

hi @devimc ,sorry for long time to see the question. I just upload the latest cc-runtime, agent, proxy, shim, and run "docker run -d --device /dev/loop0:/dev/sdc --cap-add=SYS_ADMIN xxx". Finally, it works, I can mount the device successfully.

mcastelino pushed a commit to mcastelino/runtime that referenced this issue Dec 6, 2018
Update supported versions of Kubernetes with its
corresponding CRI implementations:

- Kubernetes from 1.10.5 to 1.12.2
- cri-o from 1.10 to 1.12.0, commit:
  fa540c8e806d28c2cbcd157bdf8acf2b20990ab6 as it is needed
  for fixing the devicemapper issues when removing a pod.
  More info on this issue, see:
  cri-o/cri-o#1883
- containerd from 1.1.3 to 1.2.0

Fixes: clearcontainers#927.

Depends-on: github.com/kata-containers/tests#926

Signed-off-by: Salvador Fuentes <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants