Bug 1651279

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1594484
And IIRC, soft allocation was not approved for 389:
https://pagure.io/packaging-committee/issue/474

I wonder if this approach would be acceptable/allowed by the rpmdiff tool (changing the UID after creating the user):

diff --git a/389-ds-base.spec b/389-ds-base.spec
index cc73e59..1248f81 100644
--- a/389-ds-base.spec
+++ b/389-ds-base.spec
@@ -325,13 +325,18 @@ fi
 USERNAME="dirsrv"
 GROUPNAME="dirsrv"
 HOMEDIR="/usr/share/dirsrv"
+PREFERRED_ID=389
 if ! getent group $GROUPNAME >/dev/null ; then
-    /usr/sbin/groupadd -f -r $GROUPNAME
+    /usr/sbin/groupadd -f -g $PREFERRED_ID -r $GROUPNAME
 fi
 if ! getent passwd $USERNAME >/dev/null ; then
     /usr/sbin/useradd -r -g $GROUPNAME -d $HOMEDIR -s /sbin/nologin -c "user for 389-ds-base" $USERNAME
 fi
 
+if ! getent passwd $PREFERRED_ID >/dev/null ; then
+    /usr/sbin/usermod -u $PREFERRED_ID dirsrv
+fi
+

Unfortunately looks like I need to do an official build just to test this approach (unless someone knows a way to run the rpmdiff tool against the spec file)

Please don't change uids for existing records, that has the potential of more breakage.

Per bug 1594484 comment 3, the change afe1f2fa90776c6f328ccce258e5692521223f53 introduced the initial regression, which got then made worse with subsequent changes to the .spec in an attempt to fix bug 1594484. So just reverting the relevant part of the .spec to state before afe1f2fa90776c6f328ccce258e5692521223f53 should resolve the issue.

(In reply to Jan Pazdziora from comment #6)
> Please don't change uids for existing records, that has the potential of
> more breakage.
> 
> Per bug 1594484 comment 3, the change
> afe1f2fa90776c6f328ccce258e5692521223f53 introduced the initial regression,
> which got then made worse with subsequent changes to the .spec in an attempt
> to fix bug 1594484. So just reverting the relevant part of the .spec to
> state before afe1f2fa90776c6f328ccce258e5692521223f53 should resolve the
> issue.

The problem is that we never had an acceptable approach.  You call it a regression, but it was never working for all cases.  We are also not allowed to revert it to the old way (via the Red Hat security team).  So I'm not sure how to proceed :-(

Also, what is wrong with changing the UID of "our" dirsrv user?  I could add a check to see if the user previously exists, if it does so don't touch it.  If it's a new user, then adjust the UID after creating the user.

Here is another way to do it, but I don't know yet if the RPMDiff tool is still going to reject this change:


@@ -325,11 +325,15 @@ fi
 USERNAME="dirsrv"
 GROUPNAME="dirsrv"
 HOMEDIR="/usr/share/dirsrv"
+PREFERRED_ID=389
 if ! getent group $GROUPNAME >/dev/null ; then
-    /usr/sbin/groupadd -f -r $GROUPNAME
+    /usr/sbin/groupadd -f -g $PREFERRED_ID -r $GROUPNAME
 fi
 if ! getent passwd $USERNAME >/dev/null ; then
     /usr/sbin/useradd -r -g $GROUPNAME -d $HOMEDIR -s /sbin/nologin -c "user for 389-ds-base" $USERNAME
+    if ! getent passwd $PREFERRED_ID >/dev/null ; then
+        /usr/sbin/usermod -u $PREFERRED_ID $USERNAME
+    fi
 fi

Let's not rediscover the wheel, please. Prior to afe1f2fa90776c6f328ccce258e5692521223f53 the code was

getent group $GROUPNAME >/dev/null || /usr/sbin/groupadd -f -g $ALLOCATED_GID -r $GROUPNAME
if ! getent passwd $USERNAME >/dev/null ; then
    if ! getent passwd $ALLOCATED_UID >/dev/null ; then
        /usr/sbin/useradd -r -u $ALLOCATED_UID -g $GROUPNAME -d $HOMEDIR -s /sbin/nologin -c "user for 389-ds-base" $USERNAME
    else
        /usr/sbin/useradd -r -g $GROUPNAME -d $HOMEDIR -s /sbin/nologin -c "user for 389-ds-base" $USERNAME
    fi
fi

and it worked fine, IIUIC.

Since the afe1f2fa90776c6f328ccce258e5692521223f53 commit message is

do various specfile cleanups

for the rebase bug 1470169, the change was never really asked for or acked, there does not seem any explanation why suddenly that

getent passwd $ALLOCATED_UID

was dropped. The change that went in in afe1f2fa90776c6f328ccce258e5692521223f53 (about groupadd and useradd) was a "cleanup" that should have never happened, so should be reverted to get back to the last working state.

If there was some case where things were not working, please track that in separate bugzilla that would explain in what scenario things fail. Including such a change in a cleanup commit for rebase bugzilla seems not ideal.

What exactly is Red Hat's security team's reasoning for not allowing us to have the original behaviour? Was that tracked anywhere?

For the record, could you add link to the upstream fix / patch?

(In reply to Jan Pazdziora from comment #17)
> For the record, could you add link to the upstream fix / patch?

Well it's not really upstream, I just committed the fix downstream (so it's not lost).  It will be in the next RHEL build...

Build tested:
389-ds-base-1.3.9.1-4.el7.x86_64

Steps:
# grep -E '^dirsrv:x:389:' /etc/passwd
dirsrv:x:389:389:user for 389-ds-base:/usr/share/dirsrv:/sbin/nologin

OR

# getent passwd dirsrv
dirsrv:x:389:389:user for 389-ds-base:/usr/share/dirsrv:/sbin/nologin

Marking as Verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2152