First problem statement for new LSB approach

[rjschwei]

• Initial problem statement and proposed test cases for the user naming and group naming issue that provides inconsistency across distributions

[mwichmann]

Interesting. This was an issue that was discussed many years ago and eventually largely disimissed for LSB.

http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/usernames.html has what survived in LSB, which essentially says nothing is mandatory, with uid/gid numbers explicitly left out.

[rjschwei]

This problem is becoming interesting with more and more distributed services being implemented at the application layer and distributions packaging those applications and creating the users in the packages.

There are ongoing discussions: http://lists.opensuse.org/opensuse-factory/2014-03/msg00333.html

Debian has an ID policy: https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.1

Thus I think there is a need. Lets see if we can get people talking and agreeing.

[licquia]

Good start. Test implementation detail: as written, we're now requiring /etc/passwd and /etc/group, which I'd prefer to avoid until absolutely necessary. Something like this might work better:

import pwd

for pwent in pwd.getpwall():
    if pwent.pw_name in lsbUsers:
        if (pwent.pw_uid, pwent.pw_gid) != lsbUsers[pwent.pw_name]:
            print 'UID and or GID for user %s do not match specification' %usr
            print 'found: (', uid, ',', gid, ') expected: ', lsbUsers[usr]
            sys.exit(1)

(Similar idea for groups works, using the grp module instead.)

[rjschwei]

Thanks, tests updated, although in this case not requiring /etc/passwd and /etc/goup is more of a formality. During distro testing one would expect that locally managed passwords and groups are tested. This is where I would expect "conformance" if a sysadmin sets up LDAP or other and uses different user IDs that i snot really the distros problem.

[mwichmann]

So is the thought for a kind of registry of specific name/group->id mappings? Or codifying the ranges Debian proposes?

+1 on pulling, which does not mean discussion stops.

[rjschwei]

Correct, discussion should not stop.

Your question already goes toward the "proposed solution". Right now we are just accepting the problem statement ;)

Anyway, the solution I think we want to propose and socialize needs to be two fold. Integrate the ranges that debian publishes at: https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.1 I think we also want to create a registry to support those "applications" that do need a consistent UID/GID, that would be the cloud frameworks at this point AFAIK. Thus, openstack user would actually get a prescribed UID/GID on all distributions. And last but not least the proposed solution will probably contain parts of this https://github.com/lnussel/osep_opensuse_usernames/blob/master/opensuse_usernames.txt proposal.

This should cover all the bases. The underscore proposal will probably be a bit controversial but it does make sense. And the excuse for not doing it, i.e. "a sysadmin should not assign the pop user name to a regular user" is not really valid, IMHO.

So the idea here is that we merge this problem statement, need another +1, and associated tests. Once merged I will follow up with another pull request that adds the proposed solution and moves the document from problem to proposal.

What I am now realizing is that this process introduces a discontinuity in the discussion thread as the next pull request will have it's own comment thread. However, as these threads are easily cross linked via reference I do not think that's a big deal. If others think it is we'll need to consider other options.

[herrold]

+1 on the pull. Our historical abstention in this area needs to be re-considered as times change and new use cases (here, a need for some invariant userids) Providing a common base may help avoid yet another daemon to manage dynamically assigned numerical userid values as another win

[rjschwei]

The idea was not to clutter up the top level too much, thus documents/{problems,proposals,specifications} was chosen to differentiate the different stages in the work flow, also documented in README.md. This can certainly be changed but I would not be in favor of cluttering up the top level with names. The clear distinction between documents and tests at the top level should be useful.

Processes are started via user name, not id. The system maps the user name to the user id. As is explained here: https://github.com/lnussel/osep_opensuse_usernames/blob/master/opensuse_usernames.txt the merging of "system" users and "regular" users presents a potential security problem as well. No one is arguing that the namespace should be separated, "system" users in the Linux world are simply users that get created by a package. However, there is nothing preventing a sysadmin to accidentally create a user with a different UID but an existing user name. This may lead to curious and inconsistent behavior, worst case read/write access of data that a particular user is not supposed to access. Yes, basically we could argue that the useradd command should be more restrictive, however that would probably lead to every distro having their own useradd command, that would not be a good thing.