man: clarify subid delegation

[ikerexxe]

Clarify that the subid delegation can only come from one source. This work is based on #331 (comment)

Related: #331

[alexey-tikhonov]

Thanks Iker.

There are some consequences for local user tools when you configure NSS module, would be great to document those.

[brauner]

Thank you!

[hallyn]

Does useradd fail with NSS set? This should only happen if SUB_UID_COUNT != 0 in login.defs. The comment suggests that useradd and groupadd are not possible at all with NSS. That should be fixed. If it isn't, please open a bug.

[ikerexxe]

Let me review it and I'll come back with a clarification by the beginning of next week.

[ikerexxe]

I've been testing it and the results don't match with what I wrote in the man page:

NSS	SUB_UID_COUNT	Useradd output	/etc/sub*id
files	65536	User created locally	Range created
files	0	User created locally	Range not created
invalid	65536	User created locally	Range created
invalid	0	User created locally	Range not created
sss	65536	User created locally	Range not created
sss	0	User created locally	Range not created

Thus, I would propose to change the man page again. Instead of writing

So, for example, if the subid source is configured as NSS and
<command>useradd</command> is executed, then the command will fail and the entry will not be
created in <filename>/etc/subuid</filename>.

I'd propose to write

So, for example, if the subid source is configured as sss and
<command>useradd</command> is executed, then the user will be created, but the entry will not be
created in <filename>/etc/subuid</filename>.

@hallyn @alexey-tikhonov what are your thoughts?

[alexey-tikhonov]

I'd propose to write

So, for example, if the subid source is configured as sss and
<command>useradd</command> is executed, then the user will be created, but the entry will not be
created in <filename>/etc/subuid</filename>.

if the subid source is configured as sss -> if any subid source except files is configured

[brauner]

I've been testing it and the results don't match with what I wrote in the man page:

NSS SUB_UID_COUNT Useradd output /etc/sub*id
files 65536 User created locally Range created
files 0 User created locally Range not created
invalid 65536 User created locally Range created
invalid 0 User created locally Range not created
sss 65536 User created locally Range not created
sss 0 User created locally Range not created
Thus, I would propose to change the man page again. Instead of writing

So, for example, if the subid source is configured as NSS and
<command>useradd</command> is executed, then the command will fail and the entry will not be
created in <filename>/etc/subuid</filename>.

I'd propose to write

So, for example, if the subid source is configured as sss and
<command>useradd</command> is executed, then the user will be created, but the entry will not be
created in <filename>/etc/subuid</filename>.

Should we rather fail completely in such a case? It feels that's cleaner.

[alexey-tikhonov]

That's more or less what I've been asking in #331

But it's perfectly legitimate to have users from different databases on a single host. So I don't think we should disable local user manipulation tools entirely in this case.

[hallyn]

Oh. That wasn't my intent, indeed. Can we agree that if
subid is using something other than files, and SUB_UID_COUNT is
not 0, then the user creation should simply fail? Or is it
just easier (for users) to leave it like this, since the only
recourse is to edit login.defs anyway?

[alexey-tikhonov]

I don't have strong opinion if it should fail with SUB_UID_COUNT != 0.

Imo, at the moment it's enough to carefully document current state.

[ikerexxe]

I agree with Alexey that for the moment documenting the current state should be enough. Besides, once users start using this feature I think that we'll get their feedback and we can take a more definitive decision regarding this problem.