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

Add more detailed explanations on the reasons why sudo should be avoided #101

Open
VonUniGE opened this issue Apr 11, 2018 · 4 comments
Open

Comments

@VonUniGE
Copy link

If sudo is included in a command, dockerfilelint outputs the following message:

Avoid installing or using sudo since it has unpredictable TTY and signal-forwarding behavior that can cause problems. If you absolutely need functionality similar to sudo, such as initializing the daemon as root but running it as non-root), consider using “gosu”.

This message should give more detailed explanations (or a link) on the reasons why sudo should be avoided.

There is also a question about this on unix.stackexchange.com : What exactly in the sudo behavior is unpredictable?

@SISheogorath
Copy link

This is actually a quote from the official docker best practices:

https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user

To see the official reasoning in all detail I recommend to have a look at the gosu repository:
https://github.com/tianon/gosu#gosu

@VonUniGE
Copy link
Author

Ok, the source of the message is the official Docker documentation. But, I cannot find in the gosu repository the reasoning you mention. Can you make a citation with this reasoning?

@SISheogorath
Copy link

SISheogorath commented Apr 12, 2018 via email

@VonUniGE
Copy link
Author

Thank you for your answer.

I understand that sudo is too heavy and complicated if the only goal is to drop privileges from root to a user. But if we want to test an application in different dockerized linux distributions, I think that sudo can still be useful.

I would like that dockerfilelint gives a more detailed explanation here, in order to let the user make an informed choice and not just follow a recommendation for which he doesn't understand the reasons.

But for now, I have no better formulation to propose...

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

No branches or pull requests

2 participants