alpine image permissions issues

[tydel]

When running the alpine image using the documented examples for custom home-directory persisted data:

mkdir -p ~/.weechat-container/config ~/.weechat-container/data ~/.weechat-container/cache
docker run -ti -v $HOME/.weechat-container/config:/home/user/.config/weechat -v $HOME/.weechat-container/data:/home/user/.local/share/weechat -v $HOME/.weechat-container/cache:/home/user/.cache/weechat weechat

There are permissions errors reading and writing files:

19:31   ___       __         ______________        _____
19:31   __ |     / /___________  ____/__  /_______ __  /_
19:31   __ | /| / /_  _ \  _ \  /    __  __ \  __ `/  __/
19:31   __ |/ |/ / /  __/  __/ /___  _  / / / /_/ // /_
19:31   ____/|__/  \___/\___/\____/  /_/ /_/\__,_/ \__/
19:31 WeeChat 4.3.2 [compiled on Jun  6 2024 20:29:27]
19:31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
19:31
19:31 Welcome to WeeChat!
19:31
19:31 If you are discovering WeeChat, it is recommended to read at least the quickstart guide, and the user's guide if you have some time; they explain main WeeChat concepts.
19:31 All WeeChat docs are available at: https://weechat.org/doc/
19:31
19:31 Moreover, there is inline help with /help on all commands and options (use Tab key to complete the name).
19:31 The command /fset can help to customize WeeChat.
19:31
19:31 You can add and connect to an IRC server with /server and /connect commands (see /help server).
19:31
19:31 ---
19:31
19:31 =!= Cannot create file "/home/user/.config/weechat/sec.conf.weechattmp"
19:31 =!= Error writing configuration file "/home/user/.config/weechat/sec.conf"
19:31 =!= WARNING: failed to read configuration file "/home/user/.config/weechat/sec.conf" (Permission denied)
19:31 =!= WARNING: file "/home/user/.config/weechat/sec.conf" will be overwritten on exit with default values (it is HIGHLY recommended to backup this file now)
19:31 =!= Cannot create file "/home/user/.config/weechat/weechat.conf.weechattmp"
19:31 =!= Error writing configuration file "/home/user/.config/weechat/weechat.conf"
19:31 =!= WARNING: failed to read configuration file "/home/user/.config/weechat/weechat.conf" (Permission denied)
19:31 =!= WARNING: file "/home/user/.config/weechat/weechat.conf" will be overwritten on exit with default values (it is HIGHLY recommended to backup this file now)

Note: this does not happen with the weechat/weechat:latest-debian image, only alpine.

[flashcode]

Hi,

The problem seems to be that in Alpine the user has UID 1001 while in Debian the UID is 1000.

If your host user (outside container) has UID 1000, then it works because the mounted volume has the same UID as the container.

Unfortunately, as far as I know, docker doesn't offer a way to mount the volume as another UID/GID.

And forcing the UID to 1000 in Alpine container doesn't solve the problem either, as it will not work if your host user has UID different from 1000.

So changing the permissions to give write permissions to others should work, like this:

mkdir -p ~/.weechat-container/config ~/.weechat-container/data ~/.weechat-container/cache
chmod 777 ~/.weechat-container/config ~/.weechat-container/data ~/.weechat-container/cache
docker run -ti -v $HOME/.weechat-container/config:/home/user/.config/weechat -v $HOME/.weechat-container/data:/home/user/.local/share/weechat -v $HOME/.weechat-container/cache:/home/user/.cache/weechat weechat

By the way, note that all files created by the containerized WeeChat in these directories will have UID/GID set to 1001.

[flashcode]

I just added the command chmod 777 in the README.md.

[flashcode]

I also removed the force of UID 1001 in Alpine container (honestly, I don't remember why it was forced to 1001), and I pushed new version of Alpine containers on Docker hub.

So if you have UID 1000 on host, this should work fine even without the chmod 777 command.

[redbeardymcgee]

I was having this issue, and unsatisfied with a chmod 777 solution, so I've devised this answer instead.

First, an example podman quadlet description ~/.config/containers/systemd/weechat.container

[Unit]
Description=Terminal IRC client

[Service]
Restart=on-failure
TimeoutStartSec=900

[Install]
WantedBy=default.target

[Container]
Image=docker.io/weechat/weechat:latest-alpine-slim
ContainerName=weechat
HostName=weechat
AutoUpdate=registry

# This is sufficient instead of mounting 3 volumes or changing the weechat exec command to use -d
Volume=/volumes/weechat/home/user:/home/user

PodmanArgs=-a stdin --tty=true

user_group=$(podman exec weechat sh -c 'printf $(id -u):$(id -g)')
sudo chown $user_group /volumes/weechat/home/user

This corrects the permissions for podman, and a similar approach probably would work for docker. This means I don't use chmod 777 because the correct user inside the container owns their home dir.

---

I still don't understand why I had this issue, as I see the Containerfiles run chown -R user:user /home/user.

[trygveaa]

I don't think recommending people to use chmod 777 is a good idea. If there are other people on the host they might be able to read the config, which is especially a problem if you don't use /secure and encrypt the sensitive data. I would at least add that you should remove the execute permission from ~/.weechat-container to prevent this. E.g. chmod 700 ~/.weechat-container.

Another more minor issue is that it will create the files with a different uid and you won't be able to delete some of the files with your normal user.

A better solution might be to run the WeeChat process in docker as the same uid and gid as your normal user. This means you'll not be able to write files outside of the volumes you mount though. You can do it like this:

docker run -it -u $(id -u):$(id -g) -v $HOME/.weechat-container/config:/home/user/.config/weechat -v $HOME/.weechat-container/data:/home/user/.local/share/weechat -v $HOME/.weechat-container/state:/home/user/.local/state/weechat -v $HOME/.weechat-container/cache:/home/user/.cache/weechat weechat/weechat

Note that I had to add the state directory, as that was missing from the readme.

Alternatively, just mount the whole home directory to avoid all of the permission issues:

docker run -it -u $(id -u):$(id -g) -v $HOME/.weechat-container:/home/user weechat/weechat

[redbeardymcgee]

This is still incorrectly closed as solved, despite 2 better solutions offered. I have tried to investigate why the permissions error arises in the first place but have been unable to understand the culprit. Still, chmod 777 is a security nightmare and should never under any circumstances be included in official documentation as a resolution to an upstream error.

[flashcode]

Reopening the issue to find a better solution and avoid the chmod 777.

@redbeardymcgee or @trygveaa: what do you propose? Mounting the whole directory as suggested by @trygveaa seems fine to me.

[redbeardymcgee]

Mounting the directory isn't the solution there, really. They're entering the container with the -u/--user option, bypassing the permissions error entirely. This is not necessary in any other container I run, either in docker or podman, and would not work if the host uid/gid are not 1000:1000.

Something is wrong in the container itself that I can't figure out. You're running chown -R user:user $HOME in the Containerfile, which I thought should be enough. Since that doesn't work, I'm at a loss.

IIRC, this issue is not present in the debian image.

[redbeardymcgee]

I was unable to reproduce the issue with this new quadlet configuration.

https://git.mcgee.red/redbeardymcgee/podbox/src/branch/main/quadlets/weechat

Notes from the commit:

This may not be correct still. However, podman attach weechat works correctly enough. Caveats include needing to press <ctrl-l> to reset your terminal upon attaching, except the first time, and the below error.

conmon[1519200]: conmon 35e147e48e5986338302 <nwarn>: Failed to write to remote console socket

I'm not sure if either of these are fixable from down here.

[redbeardymcgee]

I am speculating that the permissions error goes away when the persistent data volume is managed by docker or podman, rather than created manually by the user. In my quadlet example, the weechat.volume and Volume=... allows podman to create the directory without my intervention.

[d-otterplex]

user_group=$(podman exec weechat sh -c 'printf $(id -u):$(id -g)') sudo chown $user_group /volumes/weechat/home/user

This corrects the permissions for podman, and a similar approach probably would work for docker. This means I don't use chmod 777 because the correct user inside the container owns their home dir.

For (rootless) podman at least, this can be accomplished without sudo with the --userns="keep-id:uid=$UID,gid=$GID" flag, making the container map the host IDs to the container's IDs for the user (as defined with USER in the Containerfile). This has an equivalent field for quadlets with UserNS=keep-id:uid=$UID,gid=$GID. In fact, this is how I solved the issue for my own setup with a user running the container with the IDs of 1001, compared to the container's user's IDs of 1000.

~This will also work with any ID that the user has in the container, in case it is different. (This also avoids making the owner on the host side any user with that ID, if different from the running user)~

CORRECTION: all instances of the $UID/$GID need to be the ID's of the user inside the container, something along the lines of: $(podman exec weechat sh -c 'id -u') for the UID and $(podman exec weechat sh -c 'id -g') for the GID

I still don't understand why I had this issue, as I see the Containerfiles run chown -R user:user /home/user.

This is due to the Containerfile being the defining file for the image, and as such is run before the creation of the container, for which no volumes would be mounted.

[redbeardymcgee]

all instances of the $UID/$GID need to be the ID's of the user inside the container

Do you know if this is something we can determine before launching the container somehow? Can :uid=$UID,gid=$GID be omitted instead for the same effective result?

[d-otterplex]

Do you know if this is something we can determine before launching the container somehow? Can :uid=$UID,gid=$GID be omitted instead for the same effective result?

It would be best to have the useradd command in the Containerfile explicitly set a known UID/GID with their respective useradd command flags, extracting it from the image itself at runtime is not something that has an approach that I am aware of.

Setting it to the usual single user pattern IDs of 1000 would be a reasonable, predictable default, though I'm uncertain of how guaranteed that ID is in base images.

Edit: to answer the second question, from what I'm understanding, a --userns value of only keep-id maps the user's UID/GID to the same UID/GID within the container, so for any user without a UID/GID matching the one defined for the user in the container would not work.

[redbeardymcgee]

Thanks, that's interesting. I'm trying to play around with these options, but I can't seem to arrive at the optimal outcome where the host and container user both have full read-write permissions for the configurations. This isn't the only container giving me similar trouble, but the others typically also require read-write access shared between multiple containers. It's a whole other journey.

[d-otterplex]

In the scope of things that could affect in the code in this repository, setting the UID/GID to a known, consistent value would make such issues easier to resolve for containers running this image.

For people running podman encountering this issue (and more generally, for a user running containers with it), the --userns flag section of the documentation of podman-run would be helpful for understanding how to handle the permissions/ownership of files between a (non root?) podman host and its containers.

[redbeardymcgee]

I am familiar with the podman documentation as I reference it daily to prepare quadlets at https://git.mcgee.red/redbeardymcgee/podbox (migrating to quadlet-store). I'm just unable to understand something about the setup that doesn't require a host chown.

When manually creating a volume, the host user will already own the dir, so then the UserNS mapping will probably work to enable full read-write access from the host user and the container user. I'll test this...eventually.

More interesting, however, is using a weechat.volume to define the volume instead. In this case, I have tried multiple combinations of UserNS in the weechat.container and User/Group in weechat.volume to no success. The host user does not have even read permissions in any configuration I've attempted so far. For weechat this probably doesn't matter because you generally will change configurations from within the container using /set instead of modifying files directly. It's still an open problem worth solving here anyway, because I can't predict what a user may want to do with their volume.

[d-otterplex]

Ah shoot, my bad, I have worked with quadlets before, but have had issues with referencing quadlets from other quadlets (and haven't returned since the last streak of filling my host partition to the point of unusability 😅), so I'm less familiar with much beyond the .kube and .container ones in isolation. (Hopefully the documentation link helps others that stumble upon this at least!)

Perhaps it could have to do with the command line equivalent of the User field? The documentation for the .volume unit seems unusual in that it says its equivalent to --opt uid=, whereas the podman-volume-create page makes the distinction between --uid and --opt o=uid=.

This is only speculation however, since my experience with volumes is limited to the kube play syntax. In any case, I wish you the best of luck with your quadlets endeavors!