Allow commands to run as root

[tdiesler]

We have a user case where the wildfly base image does not run on openshift because the user 'jboss' is not in group 'root'

The generated Dockerfile should perhaps place the USER directive at the end and run entries and RUN commands as root.

I'll would provide a PR

CrossRef: wildfly-extras/wildfly-camel#1501

[rhuss]

Wouldn't it be also a solution (and maybe even the much better one), to fix the group issue in the base image as this is the recommended OpenShift practice anyway ?

[tdiesler]

They won't do that: jboss-dockerfiles/wildfly#47

Using a Dockerfile to build an image, I would have full control over the user running the commands. IMHO, its a limitation of the plugin that I cannot do that through config.

Reading the impl, here is a workaround that also works for me

<assembly>
    <basedir>/opt/jboss/wildfly</basedir>
    <descriptor>${project.basedir}/standalone/assembly-artifacts.xml</descriptor>
    <user>jboss:root:root</user>
</assembly>
<user>jboss</user>

Not sure if you intended the user thing to work like this. My PR uses the third part of the assembly user to set the user attribute (if not given) which would then be appended to the Dockerfile. It runs the cmds with the same user as used for chown, which would be root.

You may however have good reason to run the cmds less privileged, but the above config still seems awkward.

[rhuss]

You are always free to use a Dockerfile (see config option dockerFileDir). There is one missing link to the assembly, this is tackled in #205 . But otherwise you are free todo what you want, e.g. you could refer directly into the target/ dir, too.

Of course with an XML based configuration like this you have less degrees of freedom, and have to decide on the order of directives upfront. That works fine for simple builds, which are usually the case.

My main point with the PR is, that it depends implicitly on the order of whether the assembly is ADDed first or the command are RUN. If this call is reversed here your fix will break. This could happen anytime (of course not without a good reason), and no one will ever remember this implicit connection to this fix anymore.

That's why I said is to make it more explicit by moving this user around than sharing it over a member variable.

[tdiesler]

In a perfect world IMHO, there would be no duplication (and perhaps conflicting) config of run user and an explicit config for runCmd user.

Still, this may perhaps be over engineered. What is a good reason to not always run the cmds as root? The duplication of run user config is problematic, but can likely not be resolved without breaking compatibility.

[tdiesler]

out-of-date