RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1143066 - [RFE] The dirsrv user/group should be created in rpm %pre, and ideally with fixed uid/gid
Summary: [RFE] The dirsrv user/group should be created in rpm %pre, and ideally with f...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.1
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
: 1227533 (view as bug list)
Depends On:
Blocks: 1227598 1312968 1346311
TreeView+ depends on / blocked
 
Reported: 2014-09-17 20:39 UTC by Jan Pazdziora
Modified: 2020-09-13 21:32 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.3.5.2-1.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1346311 (view as bug list)
Environment:
Last Closed: 2016-11-03 20:34:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1616 0 None closed The dirsrv user/group should be created in rpm %pre, and ideally with fixed uid/gid 2020-10-22 16:58:00 UTC
Red Hat Product Errata RHSA-2016:2594 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description Jan Pazdziora 2014-09-17 20:39:28 UTC 
Description of problem:

The dirsrv user/group is only created when ipa-server-install is run. That makes it hard to move IPA's data from container to a data volume as in vanilla container the records won't be there and the directory server will refuse to start: Unknown user 'dirsrv'.

And if we do this, we could just as well hardcode some reasonable uid. For example, httpd does

/usr/sbin/useradd -c "Apache" -u 48 \
	-s /sbin/nologin -r -d /usr/share/httpd apache 2> /dev/null || :

For dirsrv user, uid 389 could be used (but we'd need to verify if it's not used by someone else).

Version-Release number of selected component (if applicable):

389-ds-base-1.3.1.6-26.el7_0.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. Install 389-ds-base.
2. Check /etc/group and /etc/passwd for dirsrv.

Actual results:

It's not there.

Expected results:

It should be there.

Additional info:
Comment 1 Jan Pazdziora 2014-09-17 20:42:38 UTC 
The pkiuser bugzilla is bug 1143067.
Comment 3 Jan Pazdziora 2014-09-23 10:32:44 UTC 
For the record, the guidelines for allocating uids/gids and creating the system users are at https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation
Comment 4 Jan Pazdziora 2014-09-24 08:52:58 UTC 
Per the guidelines, changing the summary/proposal to %pre.
Comment 5 Jan Pazdziora 2014-12-04 13:59:31 UTC 
If we are going to do this, it would be good to negotiate some uid/gid values with setup maintainers. Do we want to open some bugzillas for that?

I'd like to know if the uid 389 I mention above and which I plan to use for FreeIPA in containers is likely to be used.
Comment 6 Rich Megginson 2014-12-04 14:36:03 UTC 
(In reply to Jan Pazdziora from comment #5)
> If we are going to do this, it would be good to negotiate some uid/gid
> values with setup maintainers. Do we want to open some bugzillas for that?

Yes.
 
> I'd like to know if the uid 389 I mention above and which I plan to use for
> FreeIPA in containers is likely to be used.

I don't know.  We'll have to to some research to find out of uidnumber/gidnumber 389 is reserved.
Comment 7 Jan Pazdziora 2014-12-04 14:52:14 UTC 
(In reply to Rich Megginson from comment #6)
>  
> > I'd like to know if the uid 389 I mention above and which I plan to use for
> > FreeIPA in containers is likely to be used.
> 
> I don't know.  We'll have to to some research to find out of
> uidnumber/gidnumber 389 is reserved.

It does not seem to be reserved:

# grep 389 /usr/share/doc/setup/uidgid | wc -l
0
# rpm -qf /usr/share/doc/setup/uidgid
setup-2.9.0-2.fc21.noarch
#
Comment 8 Jan Pazdziora 2014-12-04 14:56:32 UTC 
(In reply to Rich Megginson from comment #6)
> (In reply to Jan Pazdziora from comment #5)
> > If we are going to do this, it would be good to negotiate some uid/gid
> > values with setup maintainers. Do we want to open some bugzillas for that?
> 
> Yes.

Filed https://fedorahosted.org/fpc/ticket/474.
Comment 10 Noriko Hosoi 2015-03-11 15:28:43 UTC 
(In reply to Jan Pazdziora from comment #8)
> (In reply to Rich Megginson from comment #6)
> > (In reply to Jan Pazdziora from comment #5)
> > > If we are going to do this, it would be good to negotiate some uid/gid
> > > values with setup maintainers. Do we want to open some bugzillas for that?
> > 
> > Yes.
> 
> Filed https://fedorahosted.org/fpc/ticket/474.

Since the ticket was closed with "nothing to do", there's no much we can do in 389?

> Status changed from meeting to closed 
> Resolution set to nothingtodo
> We discussed this at today's meeting (​​​http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-22/fpc.2015-01-22-17.01.txt), and we didn't feel that we should manage the image UID list:
Comment 11 Jan Pazdziora 2015-03-11 15:38:32 UTC 
(In reply to Noriko Hosoi from comment #10)
> 
> Since the ticket was closed with "nothing to do", there's no much we can do
> in 389?

Not really. I'd still like that addressed, albeit without the fpc group assigning a particular value.
Comment 12 Rich Megginson 2015-03-11 15:59:28 UTC 
(In reply to Jan Pazdziora from comment #11)
> (In reply to Noriko Hosoi from comment #10)
> > 
> > Since the ticket was closed with "nothing to do", there's no much we can do
> > in 389?
> 
> Not really. I'd still like that addressed, albeit without the fpc group
> assigning a particular value.

Then what exactly can we do in 389?  Change our spec files to do the useradd/groupadd with the value "389"?
Comment 13 Jan Pazdziora 2015-03-11 16:13:08 UTC 
(In reply to Rich Megginson from comment #12)
> 
> Then what exactly can we do in 389?  Change our spec files to do the
> useradd/groupadd with the value "389"?

Right, that's how I'd address it.
Comment 14 Rich Megginson 2015-03-11 16:42:51 UTC 
(In reply to Jan Pazdziora from comment #13)
> (In reply to Rich Megginson from comment #12)
> > 
> > Then what exactly can we do in 389?  Change our spec files to do the
> > useradd/groupadd with the value "389"?
> 
> Right, that's how I'd address it.

Ok, but what do we do when 389 is already in use by another user/group?
Comment 15 Jan Pazdziora 2015-03-12 08:19:34 UTC 
(In reply to Rich Megginson from comment #14)
> 
> Ok, but what do we do when 389 is already in use by another user/group?

I can see two options: 1) just use the 389 value anyway; 2) invoke useradd without the -u 389.
Comment 16 Noriko Hosoi 2015-09-22 21:53:17 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/48285
Comment 21 Mike McCune 2016-03-28 23:11:51 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 23 Noriko Hosoi 2016-05-06 20:30:35 UTC 
*** Bug 1227533 has been marked as a duplicate of this bug. ***
Comment 24 Viktor Ashirov 2016-06-28 09:08:44 UTC 
Build tested:
389-ds-base-1.3.5.8-1.el7.x86_64

[1] Before the install:
# grep '389\|dirsrv' /etc/passwd /etc/group -c
/etc/passwd:0
/etc/group:0

[2] After the install:
# grep '389\|dirsrv' /etc/passwd /etc/group 
/etc/passwd:dirsrv:x:389:389:389-ds-base:/usr/share/dirsrv:/sbin/nologin
/etc/group:dirsrv:x:389:

[3] If dirsrv user already exists with different UID:
# grep '389\|dirsrv' /etc/passwd /etc/group 
/etc/passwd:dirsrv:x:636:636:389-ds-base:/usr/share/dirsrv:/sbin/nologin
/etc/group:dirsrv:x:636:

389-ds-base installs and setup-ds.pl correctly uses disrv user by default:

# setup-ds.pl
...
==============================================================================
The server must run as a specific user in a specific group.
It is strongly recommended that this user should have no privileges
on the computer (i.e. a non-root user).  The setup procedure
will give this user/group some permissions in specific paths/files
to perform server-specific operations.

If you have not yet created a user and group for the server,
create this user and group using your native operating
system utilities.

System User [dirsrv]: 
System Group [dirsrv]: 

==============================================================================
...

[4] If UID is already taken by different user:
# grep '389\|dirsrv' /etc/passwd /etc/group 
/etc/passwd:dirsrv1:x:389:389:389-ds-base:/usr/share/dirsrv:/sbin/nologin
/etc/passwd:xdirsrv:x:390:390:389-ds-base:/usr/share/dirsrv:/sbin/nologin
/etc/passwd:dirsrv:x:391:391:389-ds-base:/usr/share/dirsrv:/sbin/nologin
/etc/group:dirsrv1:x:389:
/etc/group:xdirsrv:x:390:
/etc/group:dirsrv:x:391:

Marking as VERIFIED.
Comment 26 errata-xmlrpc 2016-11-03 20:34:10 UTC 
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://rhn.redhat.com/errata/RHSA-2016-2594.html
Note You need to log in before you can comment on or make changes to this bug.