-
Notifications
You must be signed in to change notification settings - Fork 65
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
Sudo users in containers #324
Comments
You are right that there is a bug there with regard to the endUser's
name being queried. I've been humming and hawing about what to do about
the sudo permission. For now, the existence of the "sudo" and "as-root"
permissions really creates a false sense of security due to this:
#229
Basically, an image can get root ( IN THE CONTAINER ;) ) regardless of
whether the permission is set or not :( :( :(
That bug is basically waiting on our future move to launching containers
ourselves rather than via Docker.
…On 06/13/2017 09:50 PM, mrjk wrote:
Hi,
I'm making some experiments with subuser (master branch, not stable)
and sudo subusers. In my permission file, I have:
|{ "executable": "/bin/bash", "maintainer": "mrjk", "description": "A
simple Debian 8 Shell", "access-working-directory": true,
"basic-common-permissions" : true, "sudo" : true } |
However, when I try to sudo into the image, sudo ask me the "subuser"
password, which does not exists. So it basically does not work. I
found a workaround by adding the "subuser" into allowed sudoers:
# subuserlib/classes/subuserSubmodules/run/runReadyImage.py, line 57
57 if self.subuser.permissions["sudo"]:
1 dockerfileContents+= "RUN (umask 337; echo \""+self.user.endUser.name+" ALL=(ALL) NOPASSWD: ALL\" > /e tc/sudoers.d/allowsudo )\n"
2 dockerfileContents+= "RUN (umask 337; echo \"subuser ALL=(ALL) NOPASSWD: ALL\" >>
/etc/sudoers.d/allow sudo )\n"
3 return dockerfileContents
This work well with that. BUT, I don't know if the patch is correct,
nor I don't get why "self.user.endUser.name" is queried as there is no
sign of my username inside the target container ...
But maybe I missed something here ... I've been quite quick by making
this report, but feel free to give some hints about following your
community best practices :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#324>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/ABU7-Og2IHs-u6vNwY4mhR3QpdbEtFIzks5sDuf3gaJpZM4N4_z2>.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I'm making some experiments with subuser (master branch, not stable) and sudo subusers. In my permission file, I have:
However, when I try to sudo into the image, sudo ask me the "subuser" password, which does not exists. So it basically does not work. I found a workaround by adding the "subuser" into allowed sudoers:
This work well with that. BUT, I don't know if the patch is correct, nor I don't get why "self.user.endUser.name" is queried as there is no sign of my username inside the target container ...
But maybe I missed something here ... I've been quite quick by making this report, but feel free to give some hints about following your community best practices :)
The text was updated successfully, but these errors were encountered: