Cli: tmpfs-mode not implemented in Compose file syntax

[t-anjan]

Description

This is very closely related to this issue: https://github.com/docker/cli/issues/698 and PR: https://github.com/docker/cli/pull/808 .

Although the above two links talk about tmpfs-mode, only tmpfs-size was included in the Compose file syntax.

Creating this issue here so the maintainers do not lose sight of the tmpfs-mode option.

P.S. - Is there any quick workaround / alternative way of setting the mode for tmpfs in the compose file? Or is it not possible at all? (Compose file version 3.6)

[mterron]

@t-anjan see #698 comment

[jay-to-the-dee]

This still appears to be an issue in compose file version 3.7 (unless the documentation just hasn't been updated?)

[fredleger]

still no fix for that. when most of recommendations are saying to us to never run any container as root this is clearly a NO GO for any container needing a tmpfs.

[serut]

I just found out this issue and started to crumple...
But in fact I succeeded to launch the official nginx image with fake user + read only.
Indeed, you cannot set the uid / gid when setting the tmpfs volume, but in fact the volume is created with the same rights than the existing folder in the container. So I just needed to add this in my Dockerfile :

# Allow non root user to launch nginx
RUN chown root:root /var/cache/nginx \
    && chmod 0777 /var/cache/nginx \
    && chown root:root /run \
    && chmod 0777 /run

version: '3.7'
[...]
  rs-front:
    image: <customimage>
    user: "3050:1050"
    read_only: true
    volumes:
      - type: tmpfs
        target: /var/cache/nginx
      - type: tmpfs
        target: /run
[...]

Of course it should be documented somewhere in the documentation of tmpfs !!!!!!

[fredleger]

Yes sure. But this is so hacky where a simple introduction of a new syntax
in compose file would make it faisible.
There is IMHO no technical deadlock here, since this is feasible with the
docker run command itself so it might be simple in compose (didn't look at
it deeply though).

BTW i can imagine that you instructions @serat will lead to some security
issues with so open rights on the run folder.

Cheers

Le ven. 17 avr. 2020 à 12:20, serut [e-mail] a écrit :

I just found out this issue and started to crumple...
But in fact I succeeded to launch the official nginx image with fake user

• read only.
  Indeed, you cannot set the uid / gid when setting the tmpfs volume, but in
  fact the volume is created with the same rights than the existing folder in
  the container. So I just needed to add this in my Dockerfile :

Allow non root user to launch nginx

RUN chown root:root /var/cache/nginx \

&& chmod 0777 /var/cache/nginx \

&& chown root:root /run \

&& chmod 0777 /run

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/docker/cli/issues/1285#issuecomment-615167731, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAVGM5OM4OMJLL7GPZEOOMDRNAUPNANCNFSM4FPJW4EA
.

[serut]

Salut Fred,
No I don't think this is open bar in terms of security, but I agree with you I cannot make wonderfull things as I can't know what is the future user that will run everything when I build the container. Inside an nginx alpine container, there is only the nginx.pid created by nginx inside that folder and since this is a tmpfs everything is lost on container reboot. On top of that, we are speaking about NGINX and docker alpine, so I pretty confident. This is not an official recommandation, but it can be used depending of your usecase (here that's only a reverse proxy + serves static files, there is no PHP or node.js execution).