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: 2016-11-03 20:34 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


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2594 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@redhat.com 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.