-
Notifications
You must be signed in to change notification settings - Fork 541
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
linux: username: how to figure out uid reliably #38
Comments
On Tue, Jun 30, 2015 at 04:14:17PM -0700, Brandon Philips wrote:
I don't think we need to do this. Using UID/GID is easy for the |
On Sun, Sep 06, 2015 at 02:01:42PM -0700, W. Trevor King wrote:
Of course, they'd have to enter the bundle for that ‘id’ call to work |
bumping this since we're getting past the first milestone and starting to talk about usability now. I can't think of a good way to implement a pretty common use case like User is already a platform-specific structure so I'm struggling to think of great arguments to not allow specifying a username that the runtime will map to a uid. Does anyone actually feel strongly about the runtime not mapping username->uid once the first draft is done? |
Coming back to the original issue, parsing /etc/passwd seems better to me because I don't think we can rely on getent existing in the rootfs (I can imagine cut-down rootfses that don't have it). The appc spec wording seems pretty great here imho. |
On Tue, Sep 15, 2015 at 01:49:14PM -0700, Julian Friedman wrote:
We might not have the entry in /etc/passwd though (maybe the bundle On the other hand, all my bundles will have users in /etc/passwd, so
That looks good to me too, although strangely they require numeric IDs |
Is this really required for the spec? |
On Wed, Mar 16, 2016 at 10:49:27AM -0700, Vincent Batts wrote:
@crosbymichael closed #191 as out-of-scope for the runtime 1, which |
Closes opencontainers#38 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Closing this. I agree with the assessment in #191 |
Closes opencontainers#38 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Use libcontainer/user to parse the /etc/{passwd,group} files inside the container rootfs to allow us to handle string versions of user:group specifications. This also allows us to fill the AdditionalGids fields. Signed-off-by: Aleksa Sarai <asarai@suse.com>
Right now the spec says you need to specify an OS relevant user id for the process to exec on behalf of. Many people don't think about this low-level primitive and rely on user databases like
/etc/passwd
. In order to support a user sayingapache
in the open container configuration we would need to do hacks on Linux: Sadly this requires hacks:/etc/passwd
(if it exists!)getent passwd
inside of the filesystemThis spec likely should make a recommendation on what needs to be done here and in what order if we are to support a "username".
This issues replaces #10 and is being refiled since we made a decision to be more explicit and simple for the initial draft milestone.
The text was updated successfully, but these errors were encountered: