Bug 1185342

Regarding the shadow update mentioned in the openSUSE bug, we have merged it in 15 SP3 already in case it is a requirement to resolve this issue.

The current yast2-users do not support subuids and subgids.

Support for that was added to useradd as part of fate#320422, titled "Shadow update to enable user namespaces remapping in Docker".

But there was never a request to add such feature to yast2-users as well. This bug report is the first news the YaST Team has received about that being wanted.

So we are tempted to close this as FEATURE and request a (late) Jira entry instead.

As a side note, maintenance of yast2-users (in the sense of keeping its features in sync with the shadow suite) would be much easier if yast2-users would use useradd (and other shadow tools) under the hood. We are currently working on that. Hopefully a first version will land in Tumbleweed in a couple of months. But that's not what the original developers of yast2-users did (many years ago, this is likely the oldest YaST module around) so please don't expect that yast2-users available in the current SLES will automatically gain every feature added useradd without nobody requesting it.

(In reply to Ancor Gonzalez Sosa from comment #2)
> 
> So we are tempted to close this as FEATURE and request a (late) Jira entry
> instead.

Doing so. Please create a Jira entry describing how subuids and subgids should work in yast2-user. For example, should it generate them unconditionally during installation? Should YaST offer any UI to configure them when yast2-user is executed in an already installed system? What are the expectations about AutoYaST?

(In reply to Ancor Gonzalez Sosa from comment #2)
> The current yast2-users do not support subuids and subgids.
> 
> Support for that was added to useradd as part of fate#320422, titled "Shadow
> update to enable user namespaces remapping in Docker".
> 
> But there was never a request to add such feature to yast2-users as well.
> This bug report is the first news the YaST Team has received about that
> being wanted.
> 
> So we are tempted to close this as FEATURE and request a (late) Jira entry
> instead.
> 
> As a side note, maintenance of yast2-users (in the sense of keeping its
> features in sync with the shadow suite) would be much easier if yast2-users
> would use useradd (and other shadow tools) under the hood. We are currently
> working on that. Hopefully a first version will land in Tumbleweed in a
> couple of months. But that's not what the original developers of yast2-users
> did (many years ago, this is likely the oldest YaST module around) so please
> don't expect that yast2-users available in the current SLES will
> automatically gain every feature added useradd without nobody requesting it.

The main issue here is that most outside of the YaST team aren't aware of that
technicality. IMO it's natural to assume that users created by YaST (which is
the recommended way) are complete and very similar to use created by useradd.

The referenced FATE entry also reads like noone there was aware that YaST had
separate code and just assumed that implementing the feature in shadow is
enough so that users created using YaST are also getting subuids/-gids.

IMO every mismatch between useradd and YaST is a bug. yast2-users-ng addresses
that in a future-proof way, but until then yast2-users needs fixes as well.

(In reply to Ancor Gonzalez Sosa from comment #3)
> (In reply to Ancor Gonzalez Sosa from comment #2)
> > 
> > So we are tempted to close this as FEATURE and request a (late) Jira entry
> > instead.
> 
> Doing so. Please create a Jira entry describing how subuids and subgids
> should work in yast2-user. For example, should it generate them
> unconditionally during installation? Should YaST offer any UI to configure
> them when yast2-user is executed in an already installed system? What are
> the expectations about AutoYaST?

useradd adds them unconditionally for all non-system users (https://github.com/shadow-maint/shadow/blob/7273c25cc21480de275d1632ee19b8123ec119ad/src/useradd.c#L2423), so YaST could do the same both in the installed system and AutoYaST. A UI to add them to existing users would be nice, but IMO just an optional feature.

(In reply to Fabian Vogt from comment #4)
> 
> IMO it's natural to assume that users created by YaST (which is
> the recommended way) are complete and very similar to use created by useradd.

I fear you are elevating your own expectations about how yast2-users should have been implemented (which I personally share) to the category of requirement.

> IMO every mismatch between useradd and YaST is a bug.

IMO is not.

useradd and yast2-users are two different tools. yast2-users has never claimed to be a GUI/TUI frontend for useradd[1]. In other words, mimicking the useradd behavior (current or future) was never a requirement for yast2-user.

In some sense, your sentence looks to me a bit like "every mismatch between wicked and systemd-networkd is a bug or "every mismatch between SUSEFirewall and Firewalld is a bug".

[1] Quite the opposite, that was intentionally avoided. See
https://github.com/yast/yast-users/blob/master/package/yast2-users.changes#L3687

We still claim that this is a feature request. Please read comment #3 again and file a feature. It MAY be delivered as ECO, but definitely not as a bugfix as it's not a bug.

Requesting new functionality in SLE is possible only through JIRA. And especially as it's unclear what exactly should be implemented, how, and how this is expected to be used, what is the expected default behavior, how the UI should look like (if at all), etc. We need use-cases, Docu team needs information how to document it, QA needs info how to test it, ... it's a feature request.

(In reply to Ancor Gonzalez Sosa from comment #6)
> (In reply to Fabian Vogt from comment #4)
> useradd and yast2-users are two different tools. yast2-users has never
> claimed to be a GUI/TUI frontend for useradd[1]. In other words, mimicking
> the useradd behavior (current or future) was never a requirement for
> yast2-user.

Is that explicitly documented? It is very counter intuitive and against
expectations that users created by YaST do not follow what is configured
in /etc/login.defs.

> In some sense, your sentence looks to me a bit like "every mismatch between
> wicked and systemd-networkd is a bug or "every mismatch between SUSEFirewall
> and Firewalld is a bug".

I don't think that's a valid analogy, because wicked and systemd-networkd are
alternative tools which are not used simultaneously or even installed on the
same system.

From my perspective this is more like if yast-packager didn't implement
dependency solving properly, resulting in an incomplete installation.

> [1] Quite the opposite, that was intentionally avoided. See
> https://github.com/yast/yast-users/blob/master/package/yast2-users.
> changes#L3687

Is it also written down why?

(In reply to Lukas Ocilka from comment #7)
> We still claim that this is a feature request. Please read comment #3 again
> and file a feature. It MAY be delivered as ECO, but definitely not as a
> bugfix as it's not a bug.
>
> Requesting new functionality in SLE is possible only through JIRA. And
> especially as it's unclear what exactly should be implemented, how, and how
> this is expected to be used, what is the expected default behavior, how the
> UI should look like (if at all), etc. We need use-cases, Docu team needs
> information how to document it, QA needs info how to test it, ... it's a
> feature request.

The whole process for that is a pain, but here you go:
https://jira.suse.com/browse/PM-2620

(In reply to Fabian Vogt from comment #8)
> 
> > [1] Quite the opposite, that was intentionally avoided. See
> > https://github.com/yast/yast-users/blob/master/package/yast2-users.
> > changes#L3687
> 
> Is it also written down why?

Unfortunately no. And nobody seems to know. :( I guess it looked like a wise decision back then for whatever reason(s).

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: textmode@64bit
https://openqa.opensuse.org/tests/1738613

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: textmode@64bit
https://openqa.opensuse.org/tests/1758644

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: textmode@64bit
https://openqa.opensuse.org/tests/1779789

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: textmode@64bit
https://openqa.opensuse.org/tests/1805377

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

Just for completeness, note that we are restructuring YaST Users in the master branch of the repository to rely in useradd (& friends) when creating the users. That means those changes will land in openSUSE Tumbleweed in the short term and also SLE-15-SP4 in the mid term.

See the details in this blog post https://yast.opensuse.org/blog/2021-06-28/sprint-126 or in this pull request (same information but with more links) https://github.com/yast/yast-users/pull/316

(In reply to Ancor Gonzalez Sosa from comment #14)
> Just for completeness, note that we are restructuring YaST Users in the
> master branch of the repository to rely in useradd (& friends) when creating
> the users. That means those changes will land in openSUSE Tumbleweed in the
> short term and also SLE-15-SP4 in the mid term.
> 
> See the details in this blog post
> https://yast.opensuse.org/blog/2021-06-28/sprint-126 or in this pull request
> (same information but with more links)
> https://github.com/yast/yast-users/pull/316

openQA agrees, the subuid/subgid setup is complete now: https://openqa.opensuse.org/tests/1831564#step/rootless_podman/34

Thanks!

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: textmode@64bit
https://openqa.opensuse.org/tests/1854020

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: engines_and_tools_podman
https://openqa.suse.de/tests/6660125

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: engines_and_tools_podman
https://openqa.suse.de/tests/6900937

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: textmode@64bit
https://openqa.opensuse.org/tests/1901374

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: textmode@64bit
https://openqa.opensuse.org/tests/1923730

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/7300527

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/7438623

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/7572210

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/7671843

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/7751240

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/7837439

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/7907706

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/7954473

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/8018069

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/8113186

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/8202242

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: podman_tests
https://openqa.suse.de/tests/8360528

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 56 days if nothing changes in this ticket.