Docker: UID 1000 owns ipfs process - undesired results on host systems already using UID 1000

[dasilvatek]

Checklist

• This is a bug report, not a question. Ask questions on discuss.ipfs.io.
• I have searched on the issue tracker for my bug.
• I am running the latest kubo version or have an issue updating.

Installation method

built from source

Version

Docker latest

Config

Docker latest

Description

I am running in Docker and this line in Dockerfile forces the ipfs command process to run as UID 1000, which on host systems already allocating this UID produces the undesired effect of running the ipfs process as owned by an unrelated user name:

  && adduser -D -h $IPFS_PATH -u 1000 -G users ipfs

My host system has an ipfs user configured as UID 1004 (owner of the ipfs data volume), and editing this line to its UID correctly spawns ipfs process owned by ipfs user:

  && adduser -D -h $IPFS_PATH -u 1004 -G users ipfs

The issue is obvious: statically setting this UID is problematic. I've been trying to find a way around it but have not come up with a working solution. Would increasing the UID to something like 1099 make more sense to avoid this type of user issue?

Or would it be possible to tell Dockerfile that if a local ipfs user exists on the host system to then adopt their UID? I've tried things like this to no avail because it's checking for that user in the container and not the host system:

  && if $(id -u ipfs >/dev/null 2>&1); then USER_ID=`id -u ipfs`; else USER_ID=1000; fi \
  && adduser -D -h $IPFS_PATH -u $USER_ID -G users ipfs \

Possibly using ENV variable in Dockerfile or alternatively an argument passed via docker run command? Any leads? TIA

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[Jorropo]

Would increasing the UID to something like 1099 make more sense to avoid this type of user issue?

I think so but it seems like moving the problem away more than fixing it.
I don't know enough docker to have an idea about fixing this.

[Stebalien]

Docker uses a separate user namespace unless you disable that (with, e.g., --userns=host).

[tgies]

+1. This is annoying when you have IPFS' data files already owned by a different UID on the host system passed through in a volume.

I like the way linuxserver.io Docker images handle this: by setting the UID and GID of the user inside the container to values optionally passed in magic environment variables PUID and PGID. See here: https://github.com/linuxserver/docker-baseimage-ubuntu/blob/bionic/root/etc/cont-init.d/10-adduser#L3