[gentoo-dev] dynamic groups and users

[gentoo-dev] dynamic groups and users

[Jaco Kroon]

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.

Kind Regards,
Jaco

Re: [gentoo-dev] dynamic groups and users

[Mike Gilbert]

On Thu, Aug 1, 2019 at 3:04 PM Jaco Kroon <jaco@uls.co.za> 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.

The new eclasses require you to set a fixed id, but they do not
enforce that the id is available by default. If the id is taken
already, it will allocate a new one.

User/group 0 is pretty much guaranteed to always exist, so you could
set ACCT_{GROUP,USER}_ID=0 to trigger the desired behavior.

If you're feeling crazy, this will get you a random assignment between
1 and 999, with the same fallback logic.

ACCT_GROUP_ID=$(( RANDOM % 998 + 1 ))

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]

Hi Mike,

 From user.eclass:

146         if [[ ${euid} -gt 0 ]] ; then
147             if [[ -n $(egetent passwd ${euid}) ]] ; then
148                 [[ -n ${force_uid} ]] && die "${FUNCNAME}: UID 
${euid} already taken"
149                 euid="next"
150             fi
151         else
152             eerror "Userid given but is not greater than 0 !"
153             die "${euid} is not a valid UID"
154         fi

Similar for egid.

This is the discrepency of >=0 (acct-user and acct-group) vs >0 (user) I 
was referring.  So yes, I can set it, but the underlying enewuser and 
enewgroup calls is going to kick out as per above.

Yes, I could use something like uid=1 (bin) and gid=1 (bin) which I'm 
reasonably sure use comes from baselayout and is thus almost guaranteed 
to conflict always, but the *intention* of that's unclear.  I'd rather 
(and I'm happy to write the patches, just don't want to waste my time 
doing so if it's of no interest to anyone else) have a way to explicitly 
state "I really don't care about this uid or gid value".  Also, should 
it be required to be set to eg -1 to indicate this, or is the variable 
not being set a good enough indication?  I'm included to require -1 else 
a simple typo could result in accidental dynamic allocation.

Regarding your $RANDOM idea ... that is rather crazy, and will work, 
however, I suspect you should make that % 499 ... saw an email earlier 
about the IDs should be <500 since 500 to 999 is reserved for dynamic 
allocation.

I currently have at least four dynamically allocated groups on the 
machine I'm typing this on:

tcpdump:x:999:
mrtg:x:998:
rrd:x:997:
ulsreport:x:996:

I like the idea of it being allocated from 999 downwards, and I really 
think dynamic allocation makes sense for many packages.  I do support 
the idea of predictable IDs, for packages which can trivially use shared 
storage (eg, mail).  For other packages (eg, webrtc2sip which I'm 
working with currently) it seriously doesn't matter as it'll never write 
to disk (other than the log files ...). Heck, even if it could, sharing 
that state wouldn't make much sense either.  Even something like 
asterisk being predictable makes sense, since 
/var/spool/asterisk/monitor (and a few others, as we currently are) 
could be shared between multiple hosts.

Kind Regards,

Jaco Kroon

On 2019/08/01 22:01, Mike Gilbert wrote:

> On Thu, Aug 1, 2019 at 3:04 PM Jaco Kroon <jaco@uls.co.za> 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.
> The new eclasses require you to set a fixed id, but they do not
> enforce that the id is available by default. If the id is taken
> already, it will allocate a new one.
>
> User/group 0 is pretty much guaranteed to always exist, so you could
> set ACCT_{GROUP,USER}_ID=0 to trigger the desired behavior.
>
> If you're feeling crazy, this will get you a random assignment between
> 1 and 999, with the same fallback logic.
>
> ACCT_GROUP_ID=$(( RANDOM % 998 + 1 ))
>

[-- Attachment #2: Type: text/html, Size: 5069 bytes --]

Re: [gentoo-dev] dynamic groups and users

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

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.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

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?

Would you mind to explain the motivation for that?

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?

Kind Regards,
Jaco

Re: [gentoo-dev] dynamic groups and users

[Michał Górny]

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

Re: [gentoo-dev] dynamic groups and users

[Michael Orlitzky]

On 8/2/19 5:53 AM, Michał Górny wrote:
> 
> Sure. Please preferably address two of them separately, so we can
> commit the 0 patch first, and -1 when CI is ready.
> 

Maybe I'm just feeling cynical, but what do we gain by adding support
for something that no real package should do? Is it just to avoid
thinking up any number and typing it in?

Re: [gentoo-dev] dynamic groups and users

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On Fri, 2019-08-02 at 11:46 -0400, Michael Orlitzky wrote:
> On 8/2/19 5:53 AM, Michał Górny wrote:
> > Sure. Please preferably address two of them separately, so we can
> > commit the 0 patch first, and -1 when CI is ready.
> > 
> 
> Maybe I'm just feeling cynical, but what do we gain by adding support
> for something that no real package should do? Is it just to avoid
> thinking up any number and typing it in?
> 

Given that overlays won't do proper assignment, the numbers they choose
may collide with numbers used in ::gentoo.  Forcing explicit assignment
from dynamic range is cleaner in that regard.


-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] dynamic groups and users

[Michael Orlitzky]

On 8/2/19 11:58 AM, Michał Górny wrote:
> 
> Given that overlays won't do proper assignment, the numbers they choose
> may collide with numbers used in ::gentoo.  Forcing explicit assignment
> from dynamic range is cleaner in that regard.
> 

I think it would be cleanest to leave the hacks in the overlay, and set
the desired ID to either 999 or a random number like floppym suggested.
The meaning of RANDOM is even more clear than "-1", and doesn't require
us to add both the code that's dead-on-arrival and the CI check to
ensure that it stays that way. But you're the one who's maintaining it
now so I won't argue.

Re: [gentoo-dev] dynamic groups and users

[Mike Gilbert]

On Thu, Aug 1, 2019 at 4:01 PM Mike Gilbert <floppym@gentoo.org> wrote:
> If you're feeling crazy, this will get you a random assignment between
> 1 and 999, with the same fallback logic.
>
> ACCT_GROUP_ID=$(( RANDOM % 998 + 1 ))

Correction: this is actually off by one. RANDOM % 999 will give a
number between 0 and 998, and RANDOM % 999 + 1 will give 1 to 999.

Re: [gentoo-dev] dynamic groups and users

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Fri, 2019-08-02 at 12:24 -0400, Michael Orlitzky wrote:
> On 8/2/19 11:58 AM, Michał Górny wrote:
> > Given that overlays won't do proper assignment, the numbers they choose
> > may collide with numbers used in ::gentoo.  Forcing explicit assignment
> > from dynamic range is cleaner in that regard.
> > 
> 
> I think it would be cleanest to leave the hacks in the overlay, and set
> the desired ID to either 999 or a random number like floppym suggested.
> The meaning of RANDOM is even more clear than "-1", and doesn't require
> us to add both the code that's dead-on-arrival and the CI check to
> ensure that it stays that way. But you're the one who's maintaining it
> now so I won't argue.
> 

I suppose setting it to 999 would also serve the purpose.  Jaco, do you
agree?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] dynamic groups and users

[James Cloos]

>>>>> "MO" == Michael Orlitzky <mjo@gentoo.org> writes:

MO> and set the desired ID to either 999 or a random number like
MO> floppym suggested.

Remember that there are sites where user uids still start at 500, and
even recent installs have to work there, too.

Nothing over 499 should be used for system uids.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

Hi Michał,

On 2019/08/02 19:06, Michał Górny wrote:
> On Fri, 2019-08-02 at 12:24 -0400, Michael Orlitzky wrote:
>> On 8/2/19 11:58 AM, Michał Górny wrote:
>>> Given that overlays won't do proper assignment, the numbers they choose
>>> may collide with numbers used in ::gentoo.  Forcing explicit assignment
>>> from dynamic range is cleaner in that regard.
>>>
>> I think it would be cleanest to leave the hacks in the overlay, and set
>> the desired ID to either 999 or a random number like floppym suggested.
>> The meaning of RANDOM is even more clear than "-1", and doesn't require
>> us to add both the code that's dead-on-arrival and the CI check to
>> ensure that it stays that way. But you're the one who's maintaining it
>> now so I won't argue.
>>
> I suppose setting it to 999 would also serve the purpose.  Jaco, do you
> agree?
>
No objections.

999 I think is probably as good a reserved "don't care" number as any, 
since really the first dynamic allocation will already use that.

Kind Regards,
Jaco

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

[-- Attachment #1.1: Type: text/plain, Size: 1885 bytes --]

Hi Guys,

Attaching.  It seems for some reason if I inline the patches they don't 
come through.  If I mail to myself only it works just fine.


Kind Regards,
Jaco Kroon
C.E.O.

*T:* +27 (0)12 021 0000 | *F:* +27 86 648 8561 | *E:* jaco@iewc.co.za
*W:* iewc.co.za <http://www.iewc.co.za/> | *A:* Unit 201, Building 2B, 
Sunwood Park, Queen's Crescent Lynnwood, Pretoria


	

Facebook <https://www.facebook.com/Interexcel/> Twitter 
<https://twitter.com/Interexcel/> Google+ 
<https://plus.google.com/+InterexcelCoZaPTA/posts> LinkedIn 
<http://www.linkedin.com/com/images/ico-linkedin.jpg>

<http://www.iewc.co.za/> <http://www.uls.co.za/>

This email and all contents are subject to the following disclaimer: 
View Disclaimer <http://www.iewc.co.za/email-disclaimer/>

On 2019/08/04 18:22, Jaco Kroon wrote:
> Hi Michał,
>
> On 2019/08/02 19:06, Michał Górny wrote:
>> On Fri, 2019-08-02 at 12:24 -0400, Michael Orlitzky wrote:
>>> On 8/2/19 11:58 AM, Michał Górny wrote:
>>>> Given that overlays won't do proper assignment, the numbers they 
>>>> choose
>>>> may collide with numbers used in ::gentoo.  Forcing explicit 
>>>> assignment
>>>> from dynamic range is cleaner in that regard.
>>>>
>>> I think it would be cleanest to leave the hacks in the overlay, and set
>>> the desired ID to either 999 or a random number like floppym suggested.
>>> The meaning of RANDOM is even more clear than "-1", and doesn't require
>>> us to add both the code that's dead-on-arrival and the CI check to
>>> ensure that it stays that way. But you're the one who's maintaining it
>>> now so I won't argue.
>>>
>> I suppose setting it to 999 would also serve the purpose.  Jaco, do you
>> agree?
>>
> No objections.
>
> 999 I think is probably as good a reserved "don't care" number as any, 
> since really the first dynamic allocation will already use that.
>
> Kind Regards,
> Jaco
>
>

[-- Attachment #1.2.1: Type: text/html, Size: 5882 bytes --]

[-- Attachment #1.2.2: ico-facebook.jpg --]
[-- Type: image/jpeg, Size: 1302 bytes --]

[-- Attachment #1.2.3: ico-twitter.jpg --]
[-- Type: image/jpeg, Size: 1423 bytes --]

[-- Attachment #1.2.4: ico-linkedin.jpg --]
[-- Type: image/jpeg, Size: 1444 bytes --]

[-- Attachment #1.2.5: ie.jpg --]
[-- Type: image/jpeg, Size: 3906 bytes --]

[-- Attachment #1.2.6: ulsgroup.jpg --]
[-- Type: image/jpeg, Size: 10458 bytes --]

[-- Attachment #2: 0001-acct-group-eclass-enforce-GID-0-instead-of-GID-0.patch --]
[-- Type: text/x-patch, Size: 1113 bytes --]

From bf26d929f32d02c5af1967ec4257e0f69fdf7f07 Mon Sep 17 00:00:00 2001
In-Reply-To: <cec3d8e0-fcf6-8c8c-f190-ddecb06bfcd6@uls.co.za>
References: <cec3d8e0-fcf6-8c8c-f190-ddecb06bfcd6@uls.co.za>
From: Jaco Kroon <jaco@uls.co.za>
Date: Sun, 4 Aug 2019 18:44:09 +0200
Subject: [PATCH 1/2] acct-group eclass - enforce GID > 0 instead of GID >= 0.
To: Jaco Kroon <jaco@uls.co.za>

Signed-off-by: Jaco Kroon <jaco@uls.co.za>
---
 eclass/acct-group.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
index 9eab00db690..9a759f03c57 100644
--- a/eclass/acct-group.eclass
+++ b/eclass/acct-group.eclass
@@ -87,7 +87,7 @@ acct-group_pkg_pretend() {
 
 	# verify ACCT_GROUP_ID
 	[[ -n ${ACCT_GROUP_ID} ]] || die "Ebuild error: ACCT_GROUP_ID must be set!"
-	[[ ${ACCT_GROUP_ID} -ge 0 ]] || die "Ebuild errors: ACCT_GROUP_ID=${ACCT_GROUP_ID} invalid!"
+	[[ ${ACCT_GROUP_ID} -gt 0 ]] || die "Ebuild errors: ACCT_GROUP_ID=${ACCT_GROUP_ID} invalid!"
 
 	# check for ACCT_GROUP_ID collisions early
 	if [[ -n ${ACCT_GROUP_ENFORCE_ID} ]]; then
-- 
2.21.0


[-- Attachment #3: 0002-acct-user-eclass-enforce-UID-0-instead-of-UID-0.patch --]
[-- Type: text/x-patch, Size: 1096 bytes --]

From 8ed213968674d38a6809f8638bb649d43cb1a7bf Mon Sep 17 00:00:00 2001
In-Reply-To: <cec3d8e0-fcf6-8c8c-f190-ddecb06bfcd6@uls.co.za>
References: <cec3d8e0-fcf6-8c8c-f190-ddecb06bfcd6@uls.co.za>
From: Jaco Kroon <jaco@uls.co.za>
Date: Sun, 4 Aug 2019 18:45:17 +0200
Subject: [PATCH 2/2] acct-user eclass: enforce UID > 0 instead of UID >= 0.
To: Jaco Kroon <jaco@uls.co.za>

Signed-off-by: Jaco Kroon <jaco@uls.co.za>
---
 eclass/acct-user.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index 60009643c14..1276331275c 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -279,7 +279,7 @@ acct-user_pkg_pretend() {
 
 	# verify ACCT_USER_ID
 	[[ -n ${ACCT_USER_ID} ]] || die "Ebuild error: ACCT_USER_ID must be set!"
-	[[ ${ACCT_USER_ID} -ge 0 ]] || die "Ebuild errors: ACCT_USER_ID=${ACCT_USER_ID} invalid!"
+	[[ ${ACCT_USER_ID} -gt 0 ]] || die "Ebuild errors: ACCT_USER_ID=${ACCT_USER_ID} invalid!"
 
 	# check for ACCT_USER_ID collisions early
 	if [[ -n ${ACCT_USER_ENFORCE_ID} ]]; then
-- 
2.21.0

Re: [gentoo-dev] dynamic groups and users

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

On Tue, 2019-08-06 at 13:41 +0200, Jaco Kroon wrote:
> Hi Guys,
> 
> Attaching.  It seems for some reason if I inline the patches they don't 
> come through.  If I mail to myself only it works just fine.
> 

Actually, I think it should be changed the other way around.  I don't
see any reason to prohibit having a user/group package for root.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

Hi Michał,

On 2019/08/07 17:48, Michał Górny wrote:
> On Tue, 2019-08-06 at 13:41 +0200, Jaco Kroon wrote: >> Hi Guys, >> >> Attaching. It seems for some reason if I inline the
patches they don't >> come through. If I mail to myself only it works
just fine. >> > > Actually, I think it should be changed the other way
around. I don't > see any reason to prohibit having a user/group package
for root.
Hmm, ie, remove root from baselayout?  Honestly, that's a mind stretch. 
And since it makes no sense to have any other package create a uid of
gid =0 I think the change is right.

No objection to do it the other way around, but since the value won't
make any sense it'll effectively become a "please allocate dynamically"
value - which goes against what you stated earlier of everything in
::gentoo should be "static".

Please confirm.

Kind Regards,
Jaco



[-- Attachment #2: Type: text/html, Size: 1275 bytes --]

Re: [gentoo-dev] dynamic groups and users

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

>>>>> On Wed, 07 Aug 2019, Michał Górny wrote:

> On Tue, 2019-08-06 at 13:41 +0200, Jaco Kroon wrote:
>> Attaching.  It seems for some reason if I inline the patches they don't 
>> come through.  If I mail to myself only it works just fine.

> Actually, I think it should be changed the other way around.

enewuser() checks for EUID being 0 before it even enters that code.
So you can only create the root user if you are the root user already.

> I don't see any reason to prohibit having a user/group package for
> root.

Is creation of (additional) users with UID 0 a good idea from a
security point of view? Maybe it is better to explicitly forbid it?

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]


Hi Ulrich,


> >> I don't see any reason to prohibit having a user/group package for
>> root. > > Is creation of (additional) users with UID 0 a good idea
from a > security point of view? Maybe it is better to explicitly forbid
it? > I believe the current code already prevents re-use of an already
used UID value.  So this concern, whilst valid, is already addressed I
believe.

Kind Regards,
Jaco


[-- Attachment #2: Type: text/html, Size: 740 bytes --]

Re: [gentoo-dev] dynamic groups and users

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

Hi, Jaco.

On Thu, 2019-08-01 at 21:04 +0200, Jaco Kroon wrote:
> 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"?
> 

I've just pushed the patch permitting -1.  Enjoy!

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]