podman: 2.2.0 regression: can't create service when /root/ is write protected

Arch Linux, Podman 2.2.0-1.

Podman fails to create service when /root is immutable or read-only due to failing to create /root/.config.
This is a regression of 2.2.0, I have no issue with 2.1.1.
I run Podman as root, as a system daemon, for services limited to my private network.
root is not a regular user, I find it pretty much unacceptable to give write access to /root', nothing should be saved there. I'm not sure what's going on, don't we already have /etc/containers/storage.conf`.

I’m using podman-compose but auto-generated commands that I can run to reproduce are:

podman pod create --name=flatpaksrv --share net -p 3061:80
podman create \
  --name=flatpaksrv_con
  --pod=flatpaksrv
  --label io.podman.compose.config-hash=123
  --label io.podman.compose.project=flatpaksrv
  --label io.podman.compose.version=0.0.1
  --label com.docker.compose.container-number=1
  --label com.docker.compose.service=flatpaksrv
  -e NGINX_HOST=flatpak.net.private
  -e NGINX_PORT=80
  -v /etc/podman/compose/flatpaksrv/./nginx.conf:/etc/nginx/nginx.conf:ro
  -v /srv/flatpak:/srv/flatpak
  --add-host flatpaksrv:127.0.0.1
  --add-host flatpaksrv_con:127.0.0.1
  --restart always nginx nginx
  -g daemon off;

Error message

Error: mkdir /root/.config: operation not permitted

Downgrading to 2.1.1 fixes the issue.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 1
  • Comments: 38 (25 by maintainers)

Commits related to this issue

Most upvoted comments

Yes I would still want to read the file. I don’t think there is a race condition, to wait for on read access.

There is a race condition as the file isn’t written atomically. Reading during a write would yield JSON errors. We could turn it into a read-write lock but that should really be a separate issue.

  • Keep the lock for writes
  • Actually do a temporary file + rename for updating the JSON file
  • No lock needed, and no write access at all, is necessary for reading.

Note that all of this only ever makes a difference if the service is restricted from writing to /root but allowed to read from it. I don’t really think that is very likely — if SELinux or whatever is designed to protect /root from the service, why wouldn’t reading be allowedprohibited as well?