Comments (27)
I agree. We have talked about two different things here though. One would be to set the default for the daemon so that distributions could choose the default for all containers. Red Hat Distributions would choose SLAVE as the default, since I believe this would cause the least surprise for administrators.
The second flag would be per container. (Although some have suggested per volume mount, which I think might be too complicated, for little added value.)
from runtime-spec.
@rhatdan Yeah, my description was a little imprecise. I think everything on the table is:
- Set default propagation mode for every volume of all containers
- Set default propagation mode for every volume of a single container
- Same as 2 except you can control the propagation mode of each volume's mount point
Completely agree that SLAVE
is a reasonable default -- it jives with what the intuitive behavior of volumes should be if someone is unaware of propagation modes.
I really don't think setting a default for all containers is a great idea outside of a distributor making a call on the default policy, in part because I don't think most users are aware enough of this feature to fully reason through all the effects. From the least-privilege principle, it seems like a bad idea to configure SHARED
as a default, for example, but I could easily see someone setting this as a system-wide default in order to get a single container to work.
from runtime-spec.
Yes, it seems like the namespaces list will need an additional parameter. And this parameter needs to be invalid if a "path" is given. Could someone work up a PR against https://github.com/opencontainers/specs/blob/master/config-linux.md#linux-namespaces and spec_linux.go?
from runtime-spec.
@philips This could be a property of the root mount like here opencontainers/runc#77 if we don't see a need per mount.
from runtime-spec.
@mrunalp what's 'root mount' in the context of your comment?
from runtime-spec.
rootfs mount propagation
from runtime-spec.
IMO we need flags for both rootfs and volume propagation flags to ensure things work as expected. For example, a PRIVATE
propagation for rootfs negates SLAVE
or SHARED
volume. Such surprise should be avoided.
from runtime-spec.
@rootfs Interesting point -- I probably need to do some more detailed experimenting, but I had thought that the if the mountpoint for the container's rootfs was private
, that individual mountpoints with other modes (ie, /var/lib/kubelet
with mode shared
) would be allowed. Am I missing something?
from runtime-spec.
Currently the way the mount point propogation is being done is to do a make-rprivate, on / on the host, which basically prevents any other propogation on volume mounts from working. If the make-private happened at the ROOTFS this would work. I have suggested this change but have not heard back if this fixed the problem that caused @crosbymichael to revert the change in the first place.
from runtime-spec.
That's because the propagation is recursive (MS_REC
). So if you make rootfs private
, it recursively makes all directories underneath private
. Even you flip it to slave
or shared
, private
flag still remains (there is no way you can remove a propagation mode).
from runtime-spec.
Right but rootfs would make mountpoints under /var/lib/docker/... private not everything under /, which is the current behaviour. If I just did this to /var/lib/docker/... I could later mount in /var/lib/foobar into a container and changes it propogation mode.
from runtime-spec.
That's because the propagation is recursive (MS_REC). So if you make rootfs private, it recursively makes all directories underneath private. Even you flip it to slave or shared, private flag still remains (there is no way you can remove a propagation mode).
Under the fedora build of docker 1.6, I see both propagation modes from findmnt
, but it still works as I expect (slave
):
$ docker exec -it 36e findmnt /var/lib/kubelet -o TARGET,PROPAGATION | grep kubelet
/var/lib/kubelet private,slave
So, is that really an issue?
from runtime-spec.
it is probably working for your use case, but it breaks mine. I am more interested in shared
, i.e. making container mounted directories also visible on the host. Once a shared
directory is contaminated with slave
or private
, that visibility gets lost.
from runtime-spec.
@rootfs what is your specific use-case?
On Thu, Jul 9, 2015 at 1:12 PM, Huamin Chen [email protected]
wrote:
it is probably working for your use case, but it breaks mine. I am more
interested in shared, i.e. making container mounted directories also
visible on the host.—
Reply to this email directly or view it on GitHub
#56 (comment)
.
from runtime-spec.
@pmorie
kubernetes/kubernetes#8124 (comment)
from runtime-spec.
@mrunalp I see, this makes sense putting a flag on the mounts. Perhaps we just make the rootfs another mount to cleanup the schema. So:
"mounts": [
{
"type": "bundle",
"source": "rootfs",
"destination": "/",
"sharing": "slave",
"options": ""
},
from runtime-spec.
@philips actually that option goes in the options
field as just slave and rslave.
from runtime-spec.
On Thu, Jul 09, 2015 at 11:21:26AM -0700, Brandon Philips wrote:
Perhaps we just make the rootfs another mount to cleanup the schema.
I like this approach better, since it lets us avoid having two
separate structures for root mounts and other mounts (e.g. one handles
read-only explicitly, and another which handles it along with other
things in an options field). We can always fail out if the user
doesn't specify a root-destination mount. But note that things may be
a bit trickier on Windows which requires a read/write mount 1 and
may not have a native analog for “root filesystem” [2](but I'm not
familiar enough with Windows to know what the appropriate destination
path should be).
from runtime-spec.
@crosbymichael Hrm, I thought the options field was in the fstab format and that fstab didn't allow setting propagation modes, is it possibly a gap in the fstab spec?
from runtime-spec.
fstab does not allow you to specify propagation.
from runtime-spec.
I used rootfsPropagation
in spec.Linux rootfs/runc@b68acd7
from runtime-spec.
@rootfs I agree we should just add it to the root mount too. @crosbymichael eh?
from runtime-spec.
@rootfs @philips +1, could you open a PR here to add it to the spec?
from runtime-spec.
from runtime-spec.
@rootfs I meant a PR to change spec_linux.go in this repo :)
from runtime-spec.
from runtime-spec.
Yes, closing based on #71
from runtime-spec.
Related Issues (20)
- runtime.md: State MUST be serialized with specific indentation pattern? HOT 3
- `runAsGroup` vs `supplementalGroups` HOT 3
- support PostExit Hook HOT 11
- Proposal: Add the `update` operation HOT 1
- When using Windows containers in Containerd the windows layerFolder is null and the root is blank HOT 10
- whether update container delete doc
- When running `make rust-oci-tests` getting error `container state could not be retrieved successfully.` HOT 3
- features.md: add unsafe annotation list HOT 2
- config-linux: Should we clarify when should we set the swap limit? HOT 2
- idmapped mounts: should they be applied recursively?
- dev versions don't respect semver HOT 6
- features: mountExtensions: how best to represent feature support for idmap? HOT 5
- Update `config_linux.md` when libseccomp `v2.6.0` is relased
- Why does the oci runtime spec define the runtime operation after the proposal of" runtime CLI spec" has been rejected? HOT 2
- Proposal: Support filter (Includes and Excludes) feature in LinuxSyscall HOT 7
- Proposal: Network Devices HOT 12
- Build error with clang++ 17 HOT 7
- Proposal: use pre-generated BPF filter HOT 3
- Damarcus Jones Professional
- Proposal: synchronize cgroupv1 deprecation announcements HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from runtime-spec.