0

I have a situation similar to the question that got answered here.

In the answer, it is proposed to use fixuid in the docker image so as to (and I cite)

We have created a workaround for this issue that changes a Docker container's user/group and file permissions that were set at build time to the UID/GID that the container was started with at runtime.

The project and install instructions are at: https://github.com/boxboat/fixuid

Example:

  • Docker container was built using user/group dockeruser:dockergroup as UID/GID 1000:1000.
  • Host is running as UID/GID 1001:1002.
  • Image is run with docker run -u 1001:1002. fixuid will:
  • change dockeruser UID to 1001
  • change dockergroup GID to 1002
  • change all file permissions for old dockeruser:dockergroup to 1001:1002
  • update $HOME inside container to dockeruser $HOME
  • now container and host UID/GID match and files created in the container on host mounts will match.

It can run as the ENTRYPOINT or as part of a startup script. It is installed in the container as a binary owned by root with the setuid bit, and escalates privileges to make the appropriate changes. It should only be used in development containers.

However when I try to do that I got

fixuid: already ran on this system; will not attempt to change UID/GID

and therefore the UID is not changed which causes a lot of problems

KansaiRobot
  • 7,564
  • 11
  • 71
  • 150

1 Answers1

1

As you can see in the source code of fixuid, there is a (tiny) security for not running this binary twice (because it’s setuid root so it’s very dangerous):

The file /var/run/fixuid.ran is checked for existance before running.

Looks like someone probably run the fixuid binary during the boot-up phase. Maybe in an entrypoint (that may call another entrypoint and so on), or after the entrypoint when actually running the command.

fixuid could be used in the entrypoint or as a shell wrapper for the command.
If you try to do both cases, you’ll get that message.

Cyrille Pontvieux
  • 2,356
  • 1
  • 21
  • 29
  • I think that could be the case. I asked a person who knew the developer who did this and apparently this is what is happening. fixuid is used in the entrypoint and then later it is called again when docker is commited. I think I will have to investigate more about this – KansaiRobot Oct 13 '20 at 01:13