Adding instructions in Dockerfile : CMD --privileged sh -c command1 && command2 ...

[alexeyp0708]

Description

Newbie. Please don't hit too hard.

It is necessary to run privileged commands during container running.

Adding instructions in Dockerfile : CMD --privileged sh -c command1 && command2 ...
You can also add such functionality to the CLI run --privileged-cmd="cmd1&&cmd2"

The command runs after the volumes are initialized.
For example, it will be possible to put such a command only before ENTRYPOINT.

This eliminates the need to assign privileges to the container to be able to execute a privileged command.
This behavior will allow administrators to expand the functionality of the container without endangering it.

[thaJeztah]

This eliminates the need to assign privileges to the container to be able to execute a privileged command. This behavior will allow administrators to expand the functionality of the container without endangering it.

Can you provide more context about what the "privileged" operation would do? Is this to run the command with --privileged ?

docker build does not allow for --privileged to be used, which is by design; containers executed during build (such as to execute RUN) are intended to provide a reproducible sandboxed environment. Container started with --privileged disable all security boundaries for the container (a container with --privileged does not "contain"), which means that such a container can compromise the host, as well as modify state of the host (making the environment no longer reproducible). See the (long) discussion on this ticket;

• docker build should support privileged operations #1916

The builder is now maintained in the BuildKit project (), and since that ticket, an alternative proposal was created;

• Implement entitlement security.unconfined buildkit#950
• Implement frontend support for RUN --security=insecure buildkit#1081

Which added --security flag to the RUN command, which is available in the experimental ("labs") Dockerfile syntax; https://docs.docker.com/reference/dockerfile/#run---security.

However, as the feature (as mentioned earier) is insecure. it requires the BuildKit configuration to be exlicitly configured to allow the feature, as well as entitlements to be passed when triggering the build; #1916 (comment)

[alexeyp0708]

@thaJeztah
Perhaps I proposed the idea a little unharmoniously.
It would be right to implement such an idea ENTRYPOINT --security=insecure or ENTRYPOINT --privileged
This idea came to me at the stage of considering issues #8177 or #3465
My target was to unmount the default volume. And the only way to disable it is to disable it in the container viaumount /volume . But this requires privileged permissions run --privileged or run --cap-add=SYS_ADMIN.
Yes, I know there is RUN --security=insecure in Dockerfile. But these instructions apply at the time of build . For example, at this moment your volumes are not mounted (buildkit) and the container networks is not connected. Volumes declared as metadata and are mounted only when the container is runned. #33842 (comment)

The purpose of this solution is to ensure that a number of privileged commands are executed in ENTRYPOINT (or before executing ENTRYPOINT ) when the container is runned. At the same time, the entire assembly has been completedand volumes are mounted and networks connected. Also at the same time, we do not assign privileges to the container, thereby maintaining its security.
RUN --security=insecure will not be able to provide this, since the volumes are not yet mounted and networks are not connected when the command is executed

[alexeyp0708]

As I understand it, it’s better to move this topic to moby/buildkit

[tonistiigi]

It is intentional that such flags from docker run can not be embedded into the image config. Docker security model implies that if user runs untrusted image, the application is restricted into container security sandbox. All insecure flags like --privileged --security-opt, --cap-add, bind mounts etc. that allow breakout from sandbox need to be set by the user from the command line.

There are some previous attempts #32801 to let the image define the exact options that it needs, and the user confirms it by allowing access to privileged features, but nothing like this is currently in the works afaik.

[alexeyp0708]

It is intentional that such flags from docker run can not be embedded into the image config. Docker security model implies that if user runs untrusted image, the application is restricted into container security sandbox. All insecure flags like --privileged --security-opt, --cap-add, bind mounts etc. that allow breakout from sandbox need to be set by the user from the command line.

There are some previous attempts #32801 to let the image define the exact options that it needs, and the user confirms it by allowing access to privileged features, but nothing like this is currently in the works afaik.

https://docs.docker.com/reference/dockerfile/#run---security

The official documentation now says differently.

Additional options are currently being added as experimental features to moby/buildkit

[tonistiigi]

Yes, I know there is RUN --security=insecure in Dockerfile. But these instructions apply at the time of build .

The purpose of this solution is to ensure that a number of privileged commands are executed in ENTRYPOINT (or before executing ENTRYPOINT ) when the container is runned.

As you said yourself RUN --security is for controlling sandbox of the build commands (and still requires allowing such behavior from CLI flags), but you were asking for saving privileged options into image metadata that would run when container is invoked.

[alexeyp0708]

As you said yourself RUN --security is for controlling sandbox of the build commands (and still requires allowing such behavior from CLI flags), but you were asking for saving privileged options into image metadata that would run when container is invoked.

The idea was that the user would have the opportunity to declare privileged commands in the Dockerfile before running ENTRYPOINT. In this case, there would be no need to assign privileges to the container (docker run --privileged)

From your findings -this means the idea is not feasible. (((

[alexeyp0708]

@tonistiigi
I assumed that the Docker concept is built according to the scheme, where ENTRYPOINT is a full-fledged deferred commit, and not just part of the metadata for CLI docker run.

RUN commit ___ RUN commit ________ENTRYPOINT init commit____________merged  _________RUN entrypoint commit
                        \____ CLI docker run (mount, env, net) commit___/

where in the entrypoint commit the command is only initialized, but not run. RUN entrypoint which records the execution of the entry point after merging commits.

Where could be implement additional script (privileged) as additional RUN commit between merged commit and RUN entrypoint commit

But these are just thoughts out loud.

docker run - I mean docker create