Re: [gentoo-dev] dynamic groups and users

[Michał Górny]

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



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

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

Re: [gentoo-dev] dynamic groups and users

[Ulrich Mueller]

> 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


signature.asc
Description: PGP signature

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

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

Re: [gentoo-dev] dynamic groups and users

[Michał Górny]

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



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

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  | *F:* +27 86 648 8561 | *E:* j...@iewc.co.za
*W:* iewc.co.za  | *A:* Unit 201, Building 2B, 
Sunwood Park, Queen's Crescent Lynnwood, Pretoria





Facebook  Twitter 
 Google+ 
 LinkedIn 



 

This email and all contents are subject to the following disclaimer: 
View 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


>From bf26d929f32d02c5af1967ec4257e0f69fdf7f07 Mon Sep 17 00:00:00 2001
In-Reply-To: 
References: 
From: Jaco Kroon 
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 

Signed-off-by: Jaco Kroon 
---
 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

>From 8ed213968674d38a6809f8638bb649d43cb1a7bf Mon Sep 17 00:00:00 2001
In-Reply-To: 
References: 
From: Jaco Kroon 
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 

Signed-off-by: Jaco Kroon 
---
 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

[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

[James Cloos]

> "MO" == Michael Orlitzky  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  OpenPGP: 0x997A9F17ED7DAEA6

Re: [gentoo-dev] dynamic groups and users

[Michał Górny]

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



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] dynamic groups and users

[Mike Gilbert]

On Thu, Aug 1, 2019 at 4:01 PM Mike Gilbert  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

[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

[Michał Górny]

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



signature.asc
Description: This is a digitally signed message part

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]

Dnia August 2, 2019 9:14:56 AM UTC, Jaco Kroon  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

[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]

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



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] dynamic groups and users

[Jaco Kroon]

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  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

[Mike Gilbert]

On Thu, Aug 1, 2019 at 3:04 PM 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.

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 ))

[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