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

Include setcap binary #124

Open
recmo opened this issue Jul 13, 2021 · 6 comments
Open

Include setcap binary #124

recmo opened this issue Jul 13, 2021 · 6 comments
Assignees

Comments

@recmo
Copy link

recmo commented Jul 13, 2021

How could this project be improved?

To allow a non-root executable to bind privileged ports like 80 they need to have the cap_net_bind_service capability set, which is done in the build container using

RUN setcap cap_net_bind_service=+ep /my-app

But setcap is not available in the image, requiring the addition of a dependency install

RUN sudo apt-get update && \
    sudo apt-get install -yq libcap2-bin && \
    sudo apt-get clean && sudo rm -rf /var/lib/apt/lists/*

It would be great if libcap2-bin and thus setcap are available in the emk/rust-musl-builder image.

If you're interested in implementing this feature yourself, how could I help you?

@TueHenriksen
Copy link

Hi @recmo
Just of curiosity (I am not involved in this project), why would you need to change capabilities inside a container that is only used for compiling applications? Are you maybe running your Rust application inside this container?

@recmo
Copy link
Author

recmo commented Aug 19, 2021

It's moved to a final FROM scratch container. Capabilities are preserved during this move since they are extended attributes. I need to do this in the build container because setcap is not available in FROM scratch (and installing it defeats the purpose).

IMHO, setting capabilities is part of the build process, just like setting the execute flag, stripping debug info and what else you'd want to do.

(Also, I am running the app in the build container, but just as a sanity check / test to make sure the compilation was successful. Some linker issues don't show up until you actually try to run it.)

@TueHenriksen
Copy link

That makes sense - I guess you could change capabilities within a normal ubuntu container after you have built it and before moving it to your scratch container?
But of cause, it adds an extra stage to your dockerfile...

@recmo
Copy link
Author

recmo commented Aug 19, 2021

I had not thought of adding an extra stage, but that would work too. Just apt-get installing it like above is also fine. I'm only proposing including it as a convenience. Consider it part of expected build tools like ld, strip, objdump, etc.

@emk
Copy link
Owner

emk commented Dec 16, 2021

I am gradually moving away from OpenSSL and libpq across the projects I maintain, as described on #126. I am unlikely to ever find the time to add new features to this image (and maintain them). My apologies.

@emk
Copy link
Owner

emk commented Dec 23, 2021

However, I do have some good news! Now that I've moved the build system to GitHub, it's relatively easy for me to add new Ubuntu packages to the image and to test that the image still works. If anyone still wants to have this, please submit a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants