Re: [gentoo-dev] dynamic groups and users

["Michał Górny" <mgorny@gentoo.org>]

Dnia August 2, 2019 9:14:56 AM UTC, Jaco Kroon <jaco@uls.co.za> napisał(a):
>Thank you Michał, much appreciated.
>
>I've in the meantime to make progress on my side picked something which
>
>was not in use in ::gentoo, so I can move forward, but it's be really 
>good to have the below feature anyway going forward.
>
>On 2019/08/01 22:47, Michał Górny wrote:
>> On Thu, 2019-08-01 at 21:04 +0200, Jaco Kroon wrote:
>>> Hi,
>>>
>>> Looking at the new eclasses for acct-user and acct-group.
>>>
>>> These enforce that a group and user id should be set.
>>>
>>> This is not a requirement for enewuser nor enewgroup.
>>>
>>> As a further discrepancy, the user eclass requires >0 for the IDs,
>>> whereas the checks in acct-user and acct-group is for >= 0.
>>>
>>> Would it be ok to suggest that we allow -1 (or 0, but that could be
>>> confused with the root user/group) in acct-user and acct-group to
>>> specify "no specific id, please allocate dynamically"?
>>>
>>> Use case:  I'm building some experimental packages in an overlay,
>and I
>>> really don't care what the UID and GID values are, I just need
>something
>>> unique on the host I can use to avoid running the service as root.
>>> Guessing I could just manually useradd -r but then again ... if I do
>>> later submit these into the main tree (or other packages) then it
>>> becomes a problem, and maintaining acct-{user,group}/* outside of
>main
>>> tree could conflict with main tree at a later stage ... either way,
>>> having some way to say "I honestly don't care, just give me a random
>>> number" is probably a good thing.
>>>
>> I'll look into adding support for '-1' in a few days.  However, I'm
>> going to add QA checks to prevent it from getting into ::gentoo
>first.
>
>Assuming I understand that correctly, you're happy with -1 values going
>
>into overlays, but not into ::gentoo?

Yes.

>
>Would you mind to explain the motivation for that?

Assignments are now required by policy. We really want to support at least some of the weird use cases people requested over the time, that requires uids/gids in sync. Even though you are probably right that there are users and groups that would never make real use of that, I don't think it's worthwhile to try to make the policy more complex (and potentially breaking for some obscure uses) for no real benefit.

>
>I'm also happy to take a whack at generating a patch series for you for
>
>the eclasses themselves (not familiar with the QA check code yet), 
>including sorting out the >0 vs >=0 discrepancy, if you're happy with
>that?

Sure. Please preferably address two of them separately, so we can commit the 0 patch first, and -1 when CI is ready.

>
>Kind Regards,
>Jaco


--
Best regards, 
Michał Górny