#49088 389-ds-base rpm postinstall script bugs
Closed: wontfix None Opened 5 years ago by nhosoi.

Description of problem:

389-ds-base has a postinstall script that intends to add a passwd entry for
dirsrv, hunting for an unused uid starting at 389, like this:

dirsrv_uid=389
while [ "`getent passwd | awk -F: '{print $3}' | grep $dirsrv_uid`" != "" ]; do
  dirsrv_uid=`expr $dirsrv_uid + 1`
done

This is bad for several interacting reasons.

First, it downloads the *entire* passwd map for every loop iteration.  This is
very expensive for large ldap passwd maps, especially since such downloads are
not cached by sssd (or nscd).

Second, the loop termination test is sloppy, because the grep regexp isn't
anchored to match the entire uid, so there are many false matches, like this:

shell$ getent passwd | awk -F: '{print $3}' | grep 389
389
11389
23895
23389
5389
3389
10389
23896
23893
23890
12389
23899
23898
22389
23894
23892
23897
23891
24389
13389
25389

It actually loops until it finds a sequence of digits that does not occur in
*any* uid, which can require thousands of iterations for large passwd maps.

Third, the combination of many hosts doing many passwd downloads can cause so
much ldap abuse that getent passwd occasionally fails, which can cause an
already assigned uid to be chosen.

The script similarly tries to update the group map, with similar bad results,
but the group termination test is even sloppier ...

while [ "`getent group | grep $dirsrv_gid`" != "" ]; do

... which incorrectly matches the proposed gid *anywhere* within each group
line.

Version-Release number of selected component (if applicable):
389-ds-base-1.3.5.10-12.el7_3.x86_64

How reproducible:
Always

I'm happy to ack this, but I think there is a facility in RHEL / Fedora where we can register a name -> uid, so we can guarantee it will always be ours. Consider apache is always uid 80 for example. Should we investigate this? Because that way we wouldn't need the "random if not found" .

Replying to [comment:3 firstyear]:

I'm happy to ack this, but I think there is a facility in RHEL / Fedora where we can register a name -> uid, so we can guarantee it will always be ours. Consider apache is always uid 80 for example. Should we investigate this? Because that way we wouldn't need the "random if not found" .

Yeah... What we'd like to solve is finding out an available uid/gid. By default, we chose (389,389). When it is already taken by some other account, do you think which uid needs to be assigned?

But in what case would it already be taken? That's the point of the fedora / rhel system to reserve ids, so that no one else can take them. I think there would be very few cases 389 is already claimed.

The greatest risk is that two server end up installed with different uids for dirsrv, and it causes issue on nfs or backups, or something. Unlikely, but possible.

Still, like I said I think this conflict will be very rare, so lets go ahead with this change.

git patch file (master) -- revised following the Fedora Project allocation strategy
0001-Ticket-49088-389-ds-base-rpm-postinstall-script-bugs.2.patch

Thanks for the discussion and the review, William.

As suggested by Frank, it'd be the safest to follow the Fedora Project allocation strategy, which you also pointed out in the discussion.

Pushed to master:
28e5e15..c969a82 master -> master
commit c969a82

Pushed to 389-ds-base-1.3.5:
b9e565d..0cb9c6c 389-ds-base-1.3.5 -> 389-ds-base-1.3.5
commit 0cb9c6c

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.5 backlog

5 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2147

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

2 years ago

Login to comment on this ticket.

Metadata