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 for some discussion about the :z/:Z flags.
:z/:Z
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!
:z
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.
-v /home/myuser:/home:z
/home/myuser
user_home_dir_t
Hence, my proposal is: For Atomic Host, change /var/srv to be system_u:object_r:container_file_t:s0 by default. It can then be assumed as a default interchange point for containers and the host - no labeling required.
/var/srv
system_u:object_r:container_file_t:s0
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.
seems reasonable to me.
@dwalsh, mind weighing in?
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.
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.
/srv
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.
-v /srv/somedata
/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
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. :)
migrated to https://github.com/coreos/fedora-coreos-tracker/issues/42
Metadata Update from @dustymabe: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.