linux: figuring out the uid/gid

[philips]

A config.json may specify a string "username" on Linux as the user to execute the process as. The trouble is we need to know what uid/gid this maps to inside of the container. 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.

[jonboulle]

Also important to note that the latter is a potential attack vector.

[mrunalp]

A viable option may be to punt this to higher level code and just allow numeric uid/gid/groups in the spec for Linux.

[LK4D4]

I like idea of numerical representation. Some implementations can provide extension with names, but numbers are easier for spec I think.

[thecloudtaylor]

The windows implementation of a user number would be a SID's (https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx). There are a set of 'well known SIDs' as well as per-user SIDs.

[philips]

@jonboulle If you execute the "passwd probe process" with the same level of permissions as the process it seems equivalent "security risk".

[mrunalp]

There is also a question of how to represent this in the spec. Make it OS specific or jam all fields into the object and the json only sets what it needs for that OS?

[thecloudtaylor]

At the OCF level I'd prefer to find an OS agnostic options when ever possible (it will only strengthen the spec) - then upper levels can, at there option, use other more specific and even OS specific terms.

For Example:
If in the OCF JSON we could find a common string - i.e. SID for windows and UID for Linux. Then the upper layer could for Windows say "Administrator" (which maps to a well known SID) or for Linux "root" or even define an OS common option say "god" which maps to "Administrator" on Windows and "root" on Linux.

speaking to finding OS agnostic options - as we go though this process it might be worth identifying a method of calling out 'this is OS specific with strong intent to unify' - while there are parts of Windows I may never be able to change, there are parts that can and should be changed and while it might take a release or to before we can integrate some changes that should not remove the intent.

[philips]

After @taylorb-microsoft's feedback I think we are into the zone where this becomes an OS specific field. There is nothing common between the parsing or interpretation of the user field between OSes.

[mrunalp]

@philips @crosbymichael @vmarmol @rjnagal Any preferences on user vs uid/gid for Linux?

[thecloudtaylor]

@philips seems reasonable for the first version of OCF.

[vmarmol]

@mrunalp at this level we've always opted for low-level representation so we don't need to do lookups which can be ambiguous and complicated. +1 to uid/gid

[philips]

@vmarmol @taylorb-microsoft I am having a hard time figuring out if putting the user/group into the "shared" part of the schema provides much value. There are essentially three required fields for Linux, none of which really map to windows:

• uid int32
• gid int32
• additional gids []int32

On Windows I understand there is a "primary user identifier" but it is of a different type. Since the concepts are pretty divergent between the two operating systems I think we should make the uid/gid part of the operating system specific section of the schema.

[thecloudtaylor]

@philips - I think making this OS specific at least for 1.0 would be fine... in the long term we might be able to unify it but the reality at least for now is that the uses cases across the various OS's likely drive divergent experience anyhow.

[philips]

We decided, for now, to only take a uid/gid/additional gid and documented it here: 8af3eb6

[vmarmol]

SGTM, thanks @philips!