UID and GID should be configurable

[billimek]

With the UGID hard-coded to 666 https://github.com/StayPirate/alpine-rtorrent/blob/master/Dockerfile#L8 it prevents users from controlling which user and group should be associated with the torrent files. This is problematic when other systems need to share the files, too.

Other examples of this being configurable are:

• https://github.com/looselyrigorous/docker-rtorrent/blob/master/root/init
• https://github.com/Wonderfall/docker-rtorrent-flood/blob/master/rootfs/usr/local/bin/run.sh

[EtherealMochi]

With the UGID hard-coded to 666 https://github.com/StayPirate/alpine-rtorrent/blob/master/Dockerfile#L8 it prevents users from controlling which user and group should be associated with the torrent files. This is problematic when other systems need to share the files, too.

Other examples of this being configurable are:

• https://github.com/looselyrigorous/docker-rtorrent/blob/master/root/init
• https://github.com/Wonderfall/docker-rtorrent-flood/blob/master/rootfs/usr/local/bin/run.sh

All you have to do is add --build-arg UGID=$(id -u) to the docker run command. It is only hardcoded if the --build-arg command is not passed from what I understand.

[billimek]

Indeed, yes this can be handled at docker image build-time. However this approach omits run-time configurability as done by other implementations.

[EtherealMochi]

I am completely new to docker (just started using it about 2 weeks ago) and not a linux power user. From what I can tell from the configuration of the two you linked is that this image has a completely different function from those. From what I can tell StayPirate wanted an rtorrent docker image that runs as a separate user on the host system. The links you provided use the current host UID/GID which in turn gives the container the same permissions as the current user on the host system (if I am understanding this correctly). Maybe the intention is to have an unprivileged user on the host system with only access to the downloads/watch folder.

[dsonck92]

Personally I would like to know what the benefit would be from the runtime approach. As I see it, if you change the user/gid after the build, you essentially require chowning each time when it boots up. This adds runtime complexity whereas the current solution still allows tweaking it but does not add any complexity.

Personally I believe a docker image should be as simple as "run and expose the ports, and starts rtorrent", any tweaks are build time especially as it's easy to build on top of existing dockers. If the primary reason is not to need different built images, I can't see the issue of that. It's rather trivial to host a docker image repository.

[llndqvst]

I don't fully agree that you should avoid to do anything outside of just running the program at runtime, but I do agree that chowning a bunch of folders every time the container is run doesn't seem like the best of ideas.
I've made a fork of this repo to allow the user to set uid and gid with the docker feature --user. I've also taken the liberty to change some of the directories use to better reflect that rtorrent can be run by any user.

The changes can be checked out here:
https://github.com/llndqvst/alpine-rtorrent