linux: username: how to figure out uid reliably

[philips]

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 saying apache in the open container configuration we would need to do hacks on Linux: Sadly this requires hacks:

• parse /etc/passwd (if it exists!)
• call getent passwd inside of the filesystem

This 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.

[wking]

On Tue, Jun 30, 2015 at 04:14:17PM -0700, Brandon Philips wrote:

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 saying apache in the
open container configuration…

I don't think we need to do this. Using UID/GID is easy for the
runtime 1, and ‘id -u apache’, etc., is easy for bundle authors.

[wking]

On Sun, Sep 06, 2015 at 02:01:42PM -0700, W. Trevor King wrote:

I don't think we need to do this. Using UID/GID is easy for the
runtime [1], and ‘id -u apache’, etc., is easy for bundle authors.

Of course, they'd have to enter the bundle for that ‘id’ call to work
;). So maybe not super-trivial, but I still think we should be
offloading the UID/GID lookup to bundle-author tooling.

[julz]

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 docker run -u myuser /bin/bash without mapping usernames to uids. I think this becomes particularly important where you're trying to support 'runc exec' or having multiple bundles that share a namespace. If you consider a case where the second bundle wants to log in as a user added/modified by the first bundle, it doesn't make sense to try to create the bundle with a pre-mapped uid: the user literally may not exist (or may exist with the wrong uid) when the bundle is created. The only sane way I can think of to handle this is for the runtime to do the mapping before executing the second bundle.

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?

[julz]

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.

[wking]

On Tue, Sep 15, 2015 at 01:49:14PM -0700, Julian Friedman wrote:

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…

We might not have the entry in /etc/passwd though (maybe the bundle
intends to use NIS or LDAP to lookup the user you're asking for).

On the other hand, all my bundles will have users in /etc/passwd, so
I'm ok going with “just parse /etc/passwd” until we hear complaints
from folks using alternative systems.

The appc spec wording seems pretty great here imho.

That looks good to me too, although strangely they require numeric IDs
for supplementaryGids. I think we should use whatever logic we decide
on for both the user, group, and additionalGids.

[vbatts]

Is this really required for the spec? uid is sufficient, and if username can not be resolved, then it's undefined behavior.

[wking]

On Wed, Mar 16, 2016 at 10:49:27AM -0700, Vincent Batts wrote:

Is this really required for the spec?

@crosbymichael closed #191 as out-of-scope for the runtime 1, which
sounds fine to me 2.

[philips]

Closing this. I agree with the assessment in #191