Provide a way to override setting tmpfs

[kevinanderson1]

I am unsure of who the best people would be to fix this particular issue but I figured I would start here. After upgrading to Fedora 25 and switching to the Fedora provided Docker version I started having issues running Plex in a container due to permission errors (specifically exec permissions on files in /run).

After digging I found that it was related to oci-systemd-hook which sets /run to noexec and tmpfs. The main issue that I am hitting is the image (docker.io/linuxserver/plex) is using s6-overlay with an entrypoint of /init. From what I can tell, this causes oci-systemd-hook to think that it is booting a systemd container and setting /run to tmpfs.

Is it possible to override the hook on a per-container basis? While I could remove the hook completely I do want to test some use cases that use systemd in a container so it would be beneficial to keep if possible.

Thanks!

[rhatdan]

I actually think having noexec on /run is a bug.
If /run on my host does not have this set, we should not set it in oci-systemd-hook.
I will open a pull request to remove the noexec.

You could volume mount in a directory on /run to see if the app will work fine, with oci-systemd-hook.
-v /run/myapp:/run:Z

oci-systemd-hook looks for a program running "init" or systemd, if you could change this name to something else it would not happen.

[kevinanderson1]

I'll watch for a PR and try to run the application with it to see if that will fix it. I believe it will. I also tried to volume mount it without success. It looks like the volume mount was applied, and then the tmpfs volume mounted over top of it applying noexec to it. While I agree that changing the program name would solve it, the image in question is not built or maintained by me which is why I was checking to see if it would be possible to override the hook on a per-image basis. I'll ping the image maintainers to see if they would be open to changing the name of the ENTRYPOINT as well.

…

On Tue, Dec 20, 2016 at 8:17 AM, Daniel J Walsh ***@***.***> wrote: I actually think having noexec on /run is a bug. If /run on my host does not have this set, we should not set it in oci-systemd-hook. I will open a pull request to remove the noexec. You could volume mount in a directory on /run to see if the app will work fine, with oci-systemd-hook. -v /run/myapp:/run:Z oci-systemd-hook looks for a program running "init" or systemd, if you could change this name to something else it would not happen. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAxN_sYf8x59Nx84_MGSgBAtNXyy8DY7ks5rJ9WAgaJpZM4LRUYC> .

[rhatdan]

Of volume mounting over /run still gets a tmpfs mounted over it, then that is another bug. If a user uses a volume mount, we should not mount over it.

[rhatdan]

Looks like we have code that checks for whether or not the /run directory is a mount point and then does not create a tmpfs mount. What version of oci-systemd-hook are you using?

[kevinanderson1]

I'll give it a try again when I get home in case it was user error but I do remember seeing two mount points in the container for /run. I'll also double check the version later today but the best I can give you right now is it's the version included in Fedora 25 repositories.

…

On Tue, Dec 20, 2016 at 9:06 AM, Daniel J Walsh ***@***.***> wrote: Looks like we have code that checks for whether or not the /run directory is a mount point and then does not create a tmpfs mount. What version of oci-systemd-hook are you using? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAxN_lBhMDQ-8wNf6GIkK4GUy9y16jvSks5rJ-DkgaJpZM4LRUYC> .

[rhatdan]

Well /run/secrets would still get mounted but /run should be a bind mount not a tmpfs mount.

[kevinanderson1]

So I did some more testing and here are the results. Also here is the version information:

Name : oci-systemd-hook
Version : 0.1.4
Release : 3.git41491a3.fc25

docker run -d -v /run/app:/run:Z --name plex docker.io/linuxserver/plex:latest
(SUCCESS) Results from mount | grep /run
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)

docker run -d --tmpfs /run:rw,nosuid,nodev,mode=755 --name plex docker.io/linuxserver/plex:latest
(FAIL) Results from mount | grep /run with context removed
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k,mode=755)

Your initial suggestion of doing a volume mount does in fact work. I was trying to use the --tmpfs command line option that I found in the Docker documentation (https://docs.docker.com/engine/reference/commandline/run/#/mount-tmpfs---tmpfs).

Should that command line flag also disable the mounting of /run with restrictive permissions to respect what the user provided?

[rhatdan]

We have fixes merged for the first two issues, we no longer mount as NOEXEC and we check to make sure the max size of tmpfs is no larger then 50% of total memory.
We will look to fix the --tmpfs issue tomorrow and then put out a new oci-systemd-hook. Thanks for your effort in discovering these issues.

[kevinanderson1]

Thanks for the quick response and help with this!

[hogarthj]

Just to keep things linked up ...

https://bugzilla.redhat.com/show_bug.cgi?id=1406830 <-- fedora bug about the --tmpfs issue

This has some more detail about it and it surrounds the code looking in the mounts part of the json but --tmpfs actually populating the tmpfs part and not the mounts part ... when you use -v to create a volume it appears in mounts

[rhatdan]

We now support keeping the tmpfs