Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dist: adjust script imports to be able to use /usr/libexec #559

Merged
merged 1 commit into from
Oct 21, 2024

Conversation

cyphar
Copy link
Contributor

@cyphar cyphar commented Oct 18, 2024

In order to make installation easier for distributions, make all script imports based on a single variable that distributions can adjust based on how the script is packaged for each distribution.

Ideally we would actually install the script in /usr/libexec rather than / in our Dockerfile, but this is a simpler fix that still lets you run the script from the repo directory.

Signed-off-by: Aleksa Sarai [email protected]

In order to make installation easier for distributions, make all script
imports based on a single variable that distributions can adjust based
on how the script is packaged for each distribution.

Ideally we would actually install the script in /usr/libexec rather than
/ in our Dockerfile, but this is a simpler fix that still lets you run
the script from the repo directory.

Signed-off-by: Aleksa Sarai <[email protected]>
@konstruktoid
Copy link
Collaborator

Thanks for your PR, but in what situation do you want the script and helper libraries located in different directories?

@cyphar
Copy link
Contributor Author

cyphar commented Oct 18, 2024

  1. Distro packaging rules generally require non-executable scripts that are needed by a program be put into /usr/libexec/$pkgname. This is the case for most distributions (at least RHEL/Fedora and SUSE/openSUSE, but I think the Debian folks have something similar). Even in the absence of a strict distro policy, it wouldn't really make sense to install both docker-bench-security and helper_lib.sh in /usr/bin.
  2. Using . doesn't work if you run the script from anywhere other than the current directory. If you were to install the whole project in /opt/docker-bench-security you couldn't run it without doing cd /opt/docker-bench-security. (This patch doesn't fix this problem directly, a proper fix would be to at least use $BASH_SOURCE so you can run the script from a different directory.)

FWIW, we already have to apply this patch for the openSUSE package of this project (in our package we replace the LIBEXEC line with a proper directory). In addition to using $BASH_SOURCE a proper fix would probably also fix the Dockerfile to install the scripts in a slightly nicer way (as opposed to just COPY . /). But I don't know if you folks care about the issue enough for such a patch to make sense.

@konstruktoid
Copy link
Collaborator

LGTM.

+ for test in $LIBEXEC/tests/*.sh
+ . ./tests/1_host_configuration.sh
+ for test in $LIBEXEC/tests/*.sh
+ . ./tests/2_docker_daemon_configuration.sh
+ for test in $LIBEXEC/tests/*.sh
+ . ./tests/3_docker_daemon_configuration_files.sh
+ for test in $LIBEXEC/tests/*.sh
+ . ./tests/4_container_images.sh
+ for test in $LIBEXEC/tests/*.sh
+ . ./tests/5_container_runtime.sh
+ for test in $LIBEXEC/tests/*.sh
+ . ./tests/6_docker_security_operations.sh
+ for test in $LIBEXEC/tests/*.sh
+ . ./tests/7_docker_swarm_configuration.sh
+ for test in $LIBEXEC/tests/*.sh
+ . ./tests/8_docker_enterprise_configuration.sh
+ for test in $LIBEXEC/tests/*.sh

@konstruktoid
Copy link
Collaborator

konstruktoid commented Oct 21, 2024

Regarding the Dockerfile, I'm just going to link #405 and say that it probably won't have a high priority.

@konstruktoid konstruktoid merged commit ff26d67 into docker:master Oct 21, 2024
@konstruktoid
Copy link
Collaborator

Thanks for the PR

@cyphar cyphar deleted the dist-libexec branch October 21, 2024 07:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants