walters reported a new issue against the project: `atomic-wg` that you are following: `` SELinux and containers - a fairly nontrivial difference we carry from other distributions (Ubuntu, CL) etc. that either don't use SELinux or aren't enforcing. See [this blog](https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-caus...) for some discussion about the `:z/:Z` flags.
The fact that we require these labels to be set very, very commonly trips up people. And further, I think a big problem with `:z` is that it forces a relabel every time - it's much better to have the labels set up correctly in the first place!
Another related issue is that people do e.g. `-v /home/myuser:/home:z` which will completely break the OS which expects `/home/myuser` to be `user_home_dir_t` etc.
Hence, my proposal is: For Atomic Host, change `/var/srv` to be `system_u:object_r:container_share_t:s0` by default. It can then be *assumed* as a default interchange point for containers and the host - no labeling required.
Positives: We can start documenting this, and other tools (like a pet container one) can just assume this works.
Downsides: If we don't do this for classic as well, we'll have introduced a new special distinction between AH and classic - we currently have very few of those.
``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/505
dustymabe added a new comment to an issue you are following: `` seems reasonable to me.
@dwalsh, mind weighing in? ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/505
dwalsh added a new comment to an issue you are following: `` Why would /var/srv be totally labeled as container content? I could see /var/srv/containers or something like that.
ALso :z relabels to container_file_t:s0 not container_share_t. container_share_t is read/only to the containers, while container_file_t:s0 is writable by ALL of the containers. Labeling something container_file_t:s0 allows all of the containers to attack each others content based on SELinux. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/505
walters added a new comment to an issue you are following: ``
I could see /var/srv/containers
Sure. Though what else would one be doing in `/srv` on AH/Silverblue? That said I'm fine with a subdirectory.
Labeling something container_file_t:s0 allows all of the containers to attack each others content based on SELinux.
One use case I have is for different "pet" containers to be able to easily exchange data. Or in general, to run a perhaps less-trusted container, point it at `-v /srv/somedata`, and then kill it. At that point I can safely interact with `/srv/somedata`.
To rephrase the original rationale: If you prefix your bind mount with `/srv`[1] then you don't have to worry about SELinux labeling.
[1] Or whatever prefix we decide on ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/505
mrguitar added a new comment to an issue you are following: `` can we agree on /var/srv/containers/ for atomic and /srv/containers as a sensible default on fedora?
Maybe the toolbox package can provide that dir. :) ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/505
The status of the issue: `RFC: Make /var/srv system_u:object_r:container_file_t:s0 by default` of project: `atomic-wg` has been updated to: Closed as Duplicate by dustymabe.
dustymabe added a new comment to an issue you are following: `` migrated to https://github.com/coreos/fedora-coreos-tracker/issues/42 ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/505
atomic@lists.stg.fedoraproject.org