Give option to run bareos-client as UID/GID

[pszafer]

Hi,

I'm running yours image of bareos-client on synology.
By default Alpine package creates user bareos which id is 100 and gid is 101.
https://git.alpinelinux.org/aports/tree/community/bareos/bareos.pre-install

Unfortunately since DSM6 I think it's impossible to create user with such small ID... so I end up with permission denied on each new directory.

Maybe you could give an option for environment variables:

• BAREOS_UID_MAPPING: 5555, BAREOS_GID_MAPPING: 5555

and then just before installing apk add bareos invoke

addgroup -S bareos -g $BAREOS_GID_MAPPING 2>/dev/null
adduser -S -D -H -h /var/lib/bareos -s /sbin/nologin -G bareos -g bareos -u $BAREOS_UID_MAPPING bareos 2>/dev/null

[Ceiku]

This issue is present on the bareos user on debian using the :latest tag as well, results in uid:gid as 101:101 for me.
The UID and GID issue is only on linux hosts, as the windows tray bar has correct ACL on its host from installation.

Linuxserver provides setting the PUID and PGID as environmental variables in compose, this feature is present in their base images too, though they setup a lot of other basic services too. So to keep it minimal I have just added two lines in the clients docker-entrypoint.sh before we change required permissions using the usermod command.

#!/usr/bin/env bash

bareos_fd_config="/etc/bareos/bareos-fd.d/director/bareos-dir.conf"

usermod -u ${PUID} bareos
usermod -aG ${PGID} bareos
...

Now we can use these variables in our compose:

...
environment:
  - PUID=1000
  - PGID=1000
...

This is only tested on the ubuntu 19 client, but Alpine does not have usermod available on the base image, there are workarounds. So I might make the transition over to the adduser and addgroup solution proposed here that can be made into a PR for the latest Alpine and Ubuntu images.

[barcus]

i will try to find a better way to use customized uid/gid
i don't like so much both solutions (adduser & usermod)

[wucke13]

What is the rational behind specifying the user specificly at all? Wouldn't is suffice to specify the bareos user via the USER command in the docker file? Reinventing this mechanism using env variables seems like a bad idea to me.

[barcus]

I don't think so. I think USER is used by operating system to run the process and not to define its owner.
I have just tried to force USER to "bareos" or something different than "root" but bareos-fd can't start !

bareos-fd_1 | standard_init_linux.go:211: exec user process caused "permission denied"

This is not a build command but a runtime one

[wucke13]

Just to confirm, if you set USER bareos in the line before the CMD, and remove the -u bareos from the CMD, that does not work?

[barcus]

Yes, It's exactly what i tested and i got a permission denied
Also if USER is not set and -u bareos removed, bareos-fd start normaly with root permissions

[wucke13]

That baffles me. I would expect for example a systemd service to start bareos directly under another user as well, in the same way that the USER directive from docker does it. However, if doesn't work, I'm sorry to have bothered.

[barcus]

maybe related to bareos-fd, located in /usr/sbin

[barcus]

i tested manualy inside bareos-client container, i'm able to launch bareos-fd with bareos user.

[barcus]

ok i understood, it's related to docker-entrypoint.sh script
ENTRYPOINT seems to be run with USER
i have to think about that a bit more :D

[wucke13]

Any new insight on this, @barcus ? I would be happy to help if possible.

[barcus]

At this moment docker-entrypoint.sh needs to be run as root, at least to fix perm inside /etc/bareos/bareos-fd.d when people load files with wrong permissions
if we use USER variable with something else than root, docker-entrypoint will failed, also it could require to create a new user if it doesn't exist