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

Security rethink - separate users for build and run #141

Open
mc0e opened this issue Mar 4, 2015 · 1 comment
Open

Security rethink - separate users for build and run #141

mc0e opened this issue Mar 4, 2015 · 1 comment

Comments

@mc0e
Copy link

mc0e commented Mar 4, 2015

Having code files be writeable by the runtime user is bad practice. Rebuilding the container might make removing maliciously installed apps easier, but we should make it hard to do this in the first place.

The runtime user needs to be a non-root user, and different to the build time user. There's been a move to not using root for the build, which is no doubt a good thing, but it means the build user cannot assign ownership of anything to the runtime user, so we should presumably use a shared group.

supposing we have users called 'build' and 'runtime', and as well as same-named default groups, build is a member of group 'runtime'. That way the group ownership and write-mode of files can be used to make areas writeable as necessary.

Alternatively, user 'build' might have 'runtime' as its default group, meaning just the group write permissions get used to govern write at runtime. This is perhaps problematic though when files are being sourced from third parties where the permissions are not so easily controlled. e.g. from git or tarball.

@mc0e
Copy link
Author

mc0e commented Mar 4, 2015

Also, won't a random user id create problems with access to files in volumes written by a different user id?

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

1 participant