[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Sylvain Rollinet commented on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
It doesn't seem related. For me it is the same problem as described. "dotnet restore" expects to have a valid $HOME folder
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Jesse Glick commented on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
Seems related to JENKINS-39748?
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Sylvain Rollinet commented on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I have the same problem with dotnet tooling. It can be reproduced using this dummy example
node {
docker.image('microsoft/aspnetcore-build:1.0.1').inside {
sh 'dotnet new'
sh 'dotnet restore'
}
}
dotnet restore tries to create a .nuget folder in the home directory. Which is / as the user doesn't exit, so it results in a permission denied.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Mike Kobit commented on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
Some of the restrictions here could possibly be worked around by power users if a custom entrypoint was allowed to be overridden (at https://github.com/jenkinsci/docker-workflow-plugin/blob/master/src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java#L175). I haven't thought too much about the side effects, but this would allow for some more customizability, such as creating the user and group creation/mapping at startup. Another thing is that our developers already have tooling and automation built around docker, so they are not inclined to use docker.build with the Jenkinsfile. They would prefer to use the existing build plugins and tools inside of the Jenkinsfile, so being able to provide some way to mount the host Docker socket in (possible today) while also creating a user/group to allow the current -u user/group mapping would be useful.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Oliver Gondža commented on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I just noticed this is the reason why WorkflowPluginTest#sshGitInsideDocker fails in ATH:
[Pipeline] sh
[junit729626358238985] Running shell script
+ mkdir //.ssh
mkdir: cannot create directory '//.ssh': Permission denied
The actual script is sh 'mkdir ~/.ssh && echo StrictHostKeyChecking no > ~/.ssh/config'
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Oliver Gondža edited a comment on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I used the update as an example of a command that rely on environment - not a wise choice. Certainly something in rpmbuild tooling (cross building native packages sounds like a reasonable use-case for {{inside}}) failed badly as it failed to get more information about current user OS knew nothing about.I am not saying this is something this plugin should address. Perhaps this is something {{docker build run }} should care for.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Jacob Blain Christen edited a comment on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I was running into this problem when using git commands that were trying to connect to remotes via the {{ssh}} scheme. This is because ssh seems to not honor the {{$HOME}} and *must* be able to de-reference the current user from {{/etc/passwd}} and {{/etc/group}}. My work-around was to bind mount {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} as read-only volumes, e.g.:{code}def dockerSocketGID = getOutput("stat -c '%g' /var/run/docker.sock")def dockerArgs = "--env HOME=${pwd()}"dockerArgs = "${dockerArgs} --group-add ${dockerSocketGID}"dockerArgs = "${dockerArgs} --volume /etc/group:/etc/group:ro"dockerArgs = "${dockerArgs} --volume /etc/passwd:/etc/passwd:ro"dockerArgs = "${dockerArgs} --volume /etc/shadow:/etc/shadow:ro"dockerArgs = "${dockerArgs} --volume /tmp:/tmp:rw"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/tools:/var/lib/jenkins/tools:ro"dockerArgs = "${dockerArgs} --volume /var/run/docker.sock:/var/run/docker.sock:rw"docker.withRegistry(dockerRegistryUrl, dockerRegistryCredentialsId) {pullDockerImage(dockerImg).inside(dockerArgs) {// do something useful}}def pullDockerImage(imageName) {def img = docker.image(imageName)/* make sure we have the up-to-date image */img.pull()/* dance around https://issues.jenkins-ci.org/browse/JENKINS-34276 */return docker.image(img.imageName())}{code}---P.S. For added complexity with regards to bind mounts, per this article https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/, I run my Jenkins slaves as containers that bind mount their host's {{/var/run/docker.sock}}. This means that I am pulling in the host's {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} which is why this particular bind mount, {{/var/lib/jenkins/.ssh:/home/ubuntu/.ssh}}, looks the way it does (i . e. host uid=1000 is {{ubuntu}} whereas container uid=1000 is {{jenkins}}). Additionally, to cope with ssh-agent unix sockets that are normally created in the project's {{@tmp}} directory but have a limit of 108 characters and thus fall back to using {{/tmp}}, I had to add the {{--volume /tmp:/tmp:rw}}.---P.P.S All of these bind-mount gymnastics in the workflow/pipeline scripts were prior to the advent of {{docker.inside}} automagically augmenting it's {{docker run}} command with {{--volumes-from }}.
Add Comment
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Jacob Blain Christen edited a comment on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I was running into this problem when using git commands that were trying to connect to remotes via the {{ssh}} scheme. This is because ssh seems to not honor the {{$HOME}} and *must* be able to de-reference the current user from {{/etc/passwd}} and {{/etc/group}}. My work-around was to bind mount {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} as read-only volumes, e.g.:{code}def dockerSocketGID = getOutput("stat -c '%g' /var/run/docker.sock")def dockerArgs = "--env HOME=${pwd()}"dockerArgs = "${dockerArgs} --group-add ${dockerSocketGID}"dockerArgs = "${dockerArgs} --volume /etc/group:/etc/group:ro"dockerArgs = "${dockerArgs} --volume /etc/passwd:/etc/passwd:ro"dockerArgs = "${dockerArgs} --volume /etc/shadow:/etc/shadow:ro"dockerArgs = "${dockerArgs} --volume /tmp:/tmp:rw"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/tools:/var/lib/jenkins/tools:ro"dockerArgs = "${dockerArgs} --volume /var/run/docker.sock:/var/run/docker.sock:rw"docker.withRegistry(dockerRegistryUrl, dockerRegistryCredentialsId) {pullDockerImage(dockerImg).inside(dockerArgs) {// do something useful}}def pullDockerImage(imageName) {def img = docker.image(imageName)/* make sure we have the up-to-date image */img.pull()/* dance around https://issues.jenkins-ci.org/browse/JENKINS-34276 */return docker.image(img.imageName())}{code}---P.S. For added complexity with regards to bind mounts, per this article https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/, I run my Jenkins slaves as containers that bind mount their host's {{/var/run/docker.sock}}. This means that I am pulling in the host's {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} which is why this particular bind mount, {{ --volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh :ro }}, looks the way it does. Additionally, to cope with ssh-agent unix sockets that are normally created in the project's {{@tmp}} directory but have a limit of 108 characters and thus fall back to using {{/tmp}}, I had to add the {{--volume /tmp:/tmp:rw}}.---P.P.S All of these bind-mount gymnastics in the workflow/pipeline scripts were prior to the advent of {{docker.inside}} automagically augmenting it's {{docker run}} command with {{--volumes-from }}.
Add Comment
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Jacob Blain Christen edited a comment on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I was running into this problem when using git commands that were trying to connect to remotes via the {{ssh}} scheme. This is because ssh seems to not honor the {{$HOME}} and *must* be able to de-reference the current user from {{/etc/passwd}} and {{/etc/group}}. My work-around was to bind mount {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} as read-only volumes, e.g.:{code}def dockerSocketGID = getOutput("stat -c '%g' /var/run/docker.sock")def dockerArgs = "--env HOME=${pwd()}"dockerArgs = "${dockerArgs} --group-add ${dockerSocketGID}"dockerArgs = "${dockerArgs} --volume /etc/group:/etc/group:ro"dockerArgs = "${dockerArgs} --volume /etc/passwd:/etc/passwd:ro"dockerArgs = "${dockerArgs} --volume /etc/shadow:/etc/shadow:ro"dockerArgs = "${dockerArgs} --volume /tmp:/tmp:rw"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/tools:/var/lib/jenkins/tools:ro"dockerArgs = "${dockerArgs} --volume /var/run/docker.sock:/var/run/docker.sock:rw"docker.withRegistry(dockerRegistryUrl, dockerRegistryCredentialsId) {pullDockerImage(dockerImg).inside(dockerArgs) { // do something useful }}def pullDockerImage(imageName) {def img = docker.image(imageName)/* make sure we have the up-to-date image */img.pull()/* dance around https://issues.jenkins-ci.org/browse/JENKINS-34276 */return docker.image(img.imageName())}{code}P.S. For added complexity with regards to bind mounts, per this article https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/, I run my Jenkins slaves as containers that bind mount their host's {{/var/run/docker.sock}}. This means that I am pulling in the host's {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} which is why this particular bind mount, {{--volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro}}, looks the way it does. Additionally, to cope with ssh-agent unix sockets that are normally created in the project's {{@tmp}} directory but have a limit of 108 characters and thus fall back to using {{/tmp}}, I had to add the {{--volume /tmp:/tmp:rw}}.
Add Comment
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Jacob Blain Christen commented on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I was running into this problem when using git commands that were trying to connect to remotes via the ssh scheme. This is because ssh seems to not honor the $HOME and must be able to de-reference the current user from /etc/passwd and /etc/group. My work-around was to bind mount /etc/passwd, /etc/group, and /etc/shadow as read-only volumes, e.g.:
def dockerSocketGID = getOutput("stat -c '%g' /var/run/docker.sock")
def dockerArgs = "--env HOME=${pwd()}"
dockerArgs = "${dockerArgs} --group-add ${dockerSocketGID}"
dockerArgs = "${dockerArgs} --volume /etc/group:/etc/group:ro"
dockerArgs = "${dockerArgs} --volume /etc/passwd:/etc/passwd:ro"
dockerArgs = "${dockerArgs} --volume /etc/shadow:/etc/shadow:ro"
dockerArgs = "${dockerArgs} --volume /tmp:/tmp:rw"
dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro"
dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/tools:/var/lib/jenkins/tools:ro"
docker.withRegistry(dockerRegistryUrl, dockerRegistryCredentialsId) {
pullDockerImage(dockerImg).inside(dockerArgs) {
}
}
def pullDockerImage(imageName) {
def img = docker.image(imageName)
/* make sure we have the up-to-date image */
img.pull()
/* dance around https://issues.jenkins-ci.org/browse/JENKINS-34276 */
return docker.image(img.imageName())
}
P.S. For added complexity with regards to bind mounts, per this article https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/, I run my Jenkins slaves as containers that bind mount their host's /var/run/docker.sock. This means that I am pulling in the host's /etc/passwd, /etc/group, and /etc/shadow which is why this particular bind mount, -volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro, looks the way it does. Additionally, to cope with ssh-agent unix sockets that are normally created in the project's @tmp directory but have a limit of 108 characters and thus fall back to using /tmp, I had to add the -volume /tmp:/tmp:rw.
Add Comment
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Jacob Blain Christen edited a comment on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I was running into this problem when using git commands that were trying to connect to remotes via the {{ssh}} scheme. This is because ssh seems to not honor the {{$HOME}} and *must* be able to de-reference the current user from {{/etc/passwd}} and {{/etc/group}}. My work-around was to bind mount {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} as read-only volumes, e.g.:{code}def dockerSocketGID = getOutput("stat -c '%g' /var/run/docker.sock")def dockerArgs = "--env HOME=${pwd()}"dockerArgs = "${dockerArgs} --group-add ${dockerSocketGID}"dockerArgs = "${dockerArgs} --volume /etc/group:/etc/group:ro"dockerArgs = "${dockerArgs} --volume /etc/passwd:/etc/passwd:ro"dockerArgs = "${dockerArgs} --volume /etc/shadow:/etc/shadow:ro"dockerArgs = "${dockerArgs} --volume /tmp:/tmp:rw"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/tools:/var/lib/jenkins/tools:ro"dockerArgs = "${dockerArgs} --volume /var/run/docker.sock:/var/run/docker.sock:rw"docker.withRegistry(dockerRegistryUrl, dockerRegistryCredentialsId) {pullDockerImage(dockerImg).inside(dockerArgs) {// do something useful}}def pullDockerImage(imageName) {def img = docker.image(imageName)/* make sure we have the up-to-date image */img.pull()/* dance around https://issues.jenkins-ci.org/browse/JENKINS-34276 */return docker.image(img.imageName())}{code} --- P.S. For added complexity with regards to bind mounts, per this article https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/, I run my Jenkins slaves as containers that bind mount their host's {{/var/run/docker.sock}}. This means that I am pulling in the host's {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} which is why this particular bind mount, {{--volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro}}, looks the way it does. Additionally, to cope with ssh-agent unix sockets that are normally created in the project's {{@tmp}} directory but have a limit of 108 characters and thus fall back to using {{/tmp}}, I had to add the {{--volume /tmp:/tmp:rw}}. ---P.P.S All of these bind-mount gymnastics in the workflow/pipeline scripts were prior to the advent of {{docker.inside}} automagically augmenting it's {{docker run}} command with {{--volumes-from }}.
Add Comment
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Jacob Blain Christen edited a comment on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I was running into this problem when using git commands that were trying to connect to remotes via the {{ssh}} scheme. This is because ssh seems to not honor the {{$HOME}} and *must* be able to de-reference the current user from {{/etc/passwd}} and {{/etc/group}}. My work-around was to bind mount {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} as read-only volumes, e.g.:{code}def dockerSocketGID = getOutput("stat -c '%g' /var/run/docker.sock")def dockerArgs = "--env HOME=${pwd()}"dockerArgs = "${dockerArgs} --group-add ${dockerSocketGID}"dockerArgs = "${dockerArgs} --volume /etc/group:/etc/group:ro"dockerArgs = "${dockerArgs} --volume /etc/passwd:/etc/passwd:ro"dockerArgs = "${dockerArgs} --volume /etc/shadow:/etc/shadow:ro"dockerArgs = "${dockerArgs} --volume /tmp:/tmp:rw"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro"dockerArgs = "${dockerArgs} --volume /var/lib/jenkins/tools:/var/lib/jenkins/tools:ro" dockerArgs = "${dockerArgs} --volume /var/run/docker.sock:/var/run/docker.sock:rw" docker.withRegistry(dockerRegistryUrl, dockerRegistryCredentialsId) {pullDockerImage(dockerImg).inside(dockerArgs) {}}def pullDockerImage(imageName) {def img = docker.image(imageName)/* make sure we have the up-to-date image */img.pull()/* dance around https://issues.jenkins-ci.org/browse/JENKINS-34276 */return docker.image(img.imageName())}{code}P.S. For added complexity with regards to bind mounts, per this article https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/, I run my Jenkins slaves as containers that bind mount their host's {{/var/run/docker.sock}}. This means that I am pulling in the host's {{/etc/passwd}}, {{/etc/group}}, and {{/etc/shadow}} which is why this particular bind mount, {{--volume /var/lib/jenkins/.ssh:/home/ubuntu/.ssh:ro}}, looks the way it does. Additionally, to cope with ssh-agent unix sockets that are normally created in the project's {{@tmp}} directory but have a limit of 108 characters and thus fall back to using {{/tmp}}, I had to add the {{--volume /tmp:/tmp:rw}}.
Add Comment
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Oliver Gondža commented on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
I used the update as an example of a command that rely on environment - not a wise choice. Certainly something in rpmbuild tooling (cross building native packages sounds like a reasonable use-case for inside) failed badly as it failed to get more information about current user OS knew nothing about. I am not saying this is something this plugin should address. Perhaps this is something docker build should care for.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Jesse Glick commented on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
Cf. PR 57, which would not help in this case based on my comnmand-line testing:
cid=$(docker run -d fedora sleep infinity); docker exec -u $(id -u):$(id -g) $cid dnf update; docker rm -f $cid
It is unfortunate that the error is so unhelpful but that seems like a bug in the Fedora tool that could be encountered by anyone running without sudo. Really I am not sure how this could be expected to work. Typically the Jenkins agent will be running as a jenkins user or similar, and so files in the workspace need to be owned by that user so they can be read and written by other steps (or even deleted by the next build, etc.). Since the --volume option offers no apparent UID mapping feature, that means that the active processes in the container must use the same UID/GID as the agent. In general that will mean that the steps run inside the container should not expect to run as root. But for the intended usage of inside, this is not much of a restriction because it is expected that there are two kinds of commands: tool/environment setup, which should be done using build with a Dockerfile, thus cached and able to run as any USER; and actual build steps, which are focused on manipulating workspace files and should run without privilege. If your build is really “about” creating an image or otherwise configuring things at the OS level, inside is inappropriate—you probably want to use only build and maybe run/withRun. Probably this usage distinction needs to be more clearly documented. Regarding the value of $HOME, arguably that should be set (via -e) to the workspace, in lieu of anything better.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Nicolas De Loof commented on JENKINS-38438
Re: image.inside { ... } does not create full configured user account
see https://github.com/Dockins/docker-slaves-plugin/blob/master/src/main/java/it/dockins/dockerslaves/drivers/CliDockerDriver.java#L232 as a possible way to support this
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38438) image.inside { ... } does not create full configured user account
Title: Message Title
Oliver Gondža created an issue
Jenkins / JENKINS-38438
image.inside { ... } does not create full configured user account
Issue Type:
Improvement
Assignee:
Unassigned
Components:
docker-workflow-plugin
Created:
2016/Sep/22 8:23 AM
Priority:
Major
Reporter:
Oliver Gondža
The inside command shares the underlying filesystem with wokspace running docker run with --user option so the started processes inside are likely owned by the same uid/gid as their working directory. This causes problems to system tools that do not expect to run with uid/gid that does not exists in the system and its environment is no fully configured. This causes hard to debug failures as few tool expect that current user can not be looked up in /etc/passwd or the process do not have HOME variable set. Reportedly, it is not even POSIX compliant. It does not take long to find a container/tool combination that will blow up with artificial uid/gid:
$ docker run -i fedora dnf update
... # OK
$ docker run -u 4242:4242 -i fedora dnf update
Traceback (most recent call last):
File "/usr/bin/dnf", line 36, in
main.user_main(sys.argv[1:], exit_code=True)
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 185, in user_main
errcode = main(args)
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
return _main(base, args)
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 115, in _main
cli.configure(map(ucd, args))
File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 932, in configure
self.read_conf_file(opts.conffile, root, releasever, overrides)
File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1043, in read_conf_file
conf.prepend_installroot(opt)
File "/usr/lib/python2.7/site-packages/dnf/yum/config.py", line
