Very big UID and GID identifiers in the otobo-docker

[zarpi]

Hi,

I found files in the otobo image with very big UIDs and GIDs.
Eg. (format: filename|UID|GID):
./root/.cpanm/work/1613745514.6/Redis-1.998|3957780|10902869
./root/.cpanm/work/1613745514.6/Redis-1.998/README|3957780|10902869
./root/.cpanm/work/1613745514.6/Redis-1.998/LICENSE|3957780|10902869
./root/.cpanm/work/1613745514.6/Redis-1.998/MANIFEST|3957780|10902869
(...)

Is this on purpose?
The files are located in /root/.cpanm/work/
,so I suspect the permissions might have been pulled from some Perl repository.
I think they could be corrected to root:root.

I stumbled on the issue while trying to run otobo-docker under Podman environment.
The Podman runs its container as non-root user and the non-root user has limits imposed on UIDs and GIDs
it can use in the host system, so it simply throws an error while pulling the otobo image, complaining on owner/group identifiers.
With these UIDs/GIDs corrected I think there are chances to have otobo container version working under Podman :)
Full list of files - attached.
perms_bigids.zip

Regards,
Piotr

[bschmalhofer]

Hi Piotr, @zarpi,

I checked the UIDs and GIDs of ./root/.cpanm/work/1613745514.6/Redis-1.998 in a current build of the otobo-web image. The very same very big nunbers show up in the current image. The directory ./root/.cpanm/work/1613745514.6 is the working dir of the Perl module installer called cpanm. The installation of Perl modules is triggered by the command
RUN PERL_CPANM_OPT="--local-lib /opt/otobo_install/local" carton install
that is executed when the image is built. See https://github.com/RotherOSS/otobo/blob/rel-10_0/otobo.web.dockerfile.

The high UIDs and GIDs are already included in the source package of the Perl module Redis. The package can be downloaded from https://cpan.metacpan.org/authors/id/D/DA/DAMS/Redis-1.998.tar.gz . I checked that IDs by downloading the package and calling
tar tv --numeric-owner -f Redis-1.998.tar.gz

It looks like the archive is unpacked by cpanm keeping the existing UIDs and GIDs.
I'll investigate what the best practice is in that regard. My first idea is to simply remove the working dirs when the packages have been installed.

[bschmalhofer]

Hi Piotr, @zarpi,

I have adapted the Dockerfile such that /root/.cpan is removed after the Perl modules have been installed. This should do away with the very big UIDs and GIDs. I hope this helps with Podman.
The changed image will be used in OTOBO 10.0.11. Before that you can build your own image or use the image with the tag devel-rel-10_0. See
https://hub.docker.com/layers/rotheross/otobo/devel-rel-10_0/images/sha256-6685d949b2f15ccd2a345fc20cfe61cd804f4adfba7158070954f7f130e62497?context=repo

Closing this issue.

[zarpi]

Hi Bernhard, Thank you. I confirm that the problem went away. Finally I managed to run otobo in podman. I needed to do some additional permissions adjustments, though. I can write some details if you like (perhaps in docker environment these permissions do not matter). Best regards, Piotr Dnia 27 kwietnia 2021 17:11 Bernhard Schmalhofer ***@***.***> napisał(a): Hi Piotr, github.com @zarpi , I have adapted the Dockerfile such that /root/.cpan is removed after the Perl modules have been installed. This should do away with the very big UIDs and GIDs. I hope this helps with Podman. The changed image will be used in OTOBO 10.0.11. Before that you can build your own image or use the image with the tag devel-rel-10_0 . See hub.docker.com hub.docker.com Closing this issue. — You are receiving this because you were mentioned. Reply to this email directly, github.com view it on GitHub , or github.com unsubscribe .

[bschmalhofer]

Hi Piotr, @zarpi,

glad that it helped. And yes, when you have findings or suggestions please pass them on.

Best regards,
Bernhard

[zarpi]

Hi Bernhard, I’m not experienced docker or podman user, I do not know exactly how permissions in docker containers work. In podman containers are run as the “podman” normaluser on the host level. This user “podman” becomes root inside the container. This user can manage normal users inside container. Those users are just normal users on the host level (of course they are different normal users than podman user). Changes I needed to make to have otobo working in podman containers: 1. Permissions of volumes Volumes are created automatically, but they are owned by root inside containers. As installation processes inside containers are performed by normalusers (mysql, redis, otobo), they do not have write permissions to their volumes. I just adjusted those permissions to fit the users. Unfortunately I do not know how to adjust those permissions automatically, during install. Probably it could be done in docker-compose. 2. Permissions in the image. otobo_web, apart from writing files into a volume, needs to perform modifications in /opt/otobo_install/ (eg. move docker_firsttime to docker_firsttime_handled). As the owner of /opt/otobo_install is root, the installation fails. To fix this I forked the original image and chowned recursively the /opt/otobo_install to “otobo” user. After those changes, all containers started flawlessly. Best Regards, Piotr Dnia 29 kwietnia 2021 09:16 Bernhard Schmalhofer < ***@***.*** > napisał(a): Hi Piotr, github.com @zarpi , glad that it helped. And yes, when you have findings or suggestions please pass them on. Best regards, Bernhard — You are receiving this because you were mentioned. Reply to this email directly, github.com view it on GitHub , or github.com unsubscribe .

[bschmalhofer]

Hi Piotr, @zarpi,
I'm glad that it worked eventually. The file permissions are really a hassle. I checked the situation in a regular container, not using Podman. In /opt/otobo_install the only files belonging to root are:

• cpanfile
• cpanfile.snapshot
• local
  I'm not sure, that this is the best approach, but at least that is as intended. The user otobo should not be able to install additional modules into /opt/otobo_install/local as /opt/otobo/local should be used for that.

I now nothing about Podman. If changing the owner works for you, then it seems to be fine. An alternative might be to run the webserver as root. But my impression was that using a dedicated user for that is the current best practice.

Best regards,
Bernhard