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 1316580 - dirsrv service doesn't ask for pin when pin.txt is missing
Summary: dirsrv service doesn't ask for pin when pin.txt is missing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: wibrown@redhat.com
QA Contact: Viktor Ashirov
Petr Bokoc
URL:
Whiteboard:
: 1364377 1364452 1364510 1364802 (view as bug list)
Depends On: 1322167 1324983
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-10 14:16 UTC by Viktor Ashirov
Modified: 2022-03-13 14:01 UTC (History)
12 users (show)

Fixed In Version: 389-ds-base-1.3.5.10-7.el7
Doc Type: Bug Fix
Doc Text:
*ns-slapd* now correctly prompts for a pin when the `pin.txt` file is not found In previous releases, _389-ds-base_ did not display a prompt asking for a pin if the `pin.txt` file was not found, due to the fact that *systemd* captures standard input and output which _389-ds-base_ was attempting to use. With this update, _389-ds-base_ detects whether *systemd* is running on the system during startup, and uses the correct *systemd* API to display the password prompt if required. Directory Server can therefore be started without a `pin.txt` file, which allows administrators to keep *nssdb* passwords away from the system.
Clone Of:
Environment:
Last Closed: 2016-11-03 20:40:19 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1772 0 None closed RFE Systemd password agent support 2021-02-15 17:23:35 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 Viktor Ashirov 2016-03-10 14:16:45 UTC 
Description of problem:
When 389-ds is configured with SSL, but pin.txt is missing, ns-slapd starts only on non-secure port.

Version-Release number of selected component (if applicable):
389-ds-base-1.3.4.0-27.el7_2.x86_64

How reproducible:
always

Steps to Reproduce:
1. Configure DS with SSL, but don't create pin.txt
2. systemctl start dirsrv
3. systemctl status dirsrv -l

Actual results:
[root@rhel7ds ~]# systemctl status dirsrv -l
● dirsrv - 389 Directory Server rhel7ds.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2016-03-10 15:03:51 CET; 7s ago
  Process: 7672 ExecStopPost=/bin/rm -f /var/run/dirsrv/slapd-%i.pid (code=exited, status=0/SUCCESS)
  Process: 7668 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, status=0/SUCCESS)
 Main PID: 7669 (code=exited, status=1/FAILURE)

Mar 10 15:03:51 rhel7ds.brq.redhat.com ns-slapd[7668]: Enter PIN for Internal (Software) Token: [10/Mar/2016:15:03:51 +0100] - SSL alert: Security Initialization: Unable to authenticate (Netscape Portable Runtime error -8177 - The security password entered is incorrect.)
Mar 10 15:03:51 rhel7ds.brq.redhat.com ns-slapd[7668]: [10/Mar/2016:15:03:51 +0100] - ERROR: SSL Initialization Failed.  Disabling SSL.


Expected results:
On RHEL6 start-dirsrv would ask for pin:
[root@rhel6ds ~]# start-dirsrv
Starting instance "rhel6ds"
Enter PIN for Internal (Software) Token:

Additional info:
I tried adding StandardInput=tty to the dirsrv service, but then it just hangs waiting for input.

Thanks to Punit Kundal for finding the bug.
Comment 2 Noriko Hosoi 2016-03-10 20:31:55 UTC 
Yes, it is a known issue.  See the second item in the ToDos section:

http://www.port389.org/docs/389ds/design/allow-usage-of-openldap-lib-w-openssl.html#to-dos
Comment 4 Noriko Hosoi 2016-04-07 19:53:30 UTC 
I think we need a doc bug if we haven't filed it...

How to verify:
1) using systemctl
# setfacl -m g:dirsrv:rwx /var/run/systemd/ask-password
  <== This is needed unless bz 1322167 is taken care by the systemd team.

# start-dirsrv SERV_ID
Enter PIN for Internal (Software) Token: ****************************************

Or
# systemctl start dirsrv
Enter PIN for Internal (Software) Token: ****************************************

2) using the raw command line [1]
# /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-SERV_ID -i /var/run/dirsrv/slapd-SERV_ID.pid -d 0

It issues this wall message: [2]
Broadcast message from root@<host>.<domain> (Mon 2016-04-04 16:23:04 PDT):
Password entry required for 'Enter PIN for Internal (Software) Token:' (PID 26762).
Please enter password with the systemd-tty-ask-password-agent tool!

# systemd-tty-ask-password-agent
Enter PIN for Internal (Software) Token: ****************************************

[2] For some reason, the wall is not enabled on my gnome-terminal :(, but it is on xterm.  So, it is not a bug of the DS...  Just in case, the command line [1] does not issue the message, take a look at the error log.  The similar message is logged to run systemd-tty-ask-password-agent.
Comment 5 wibrown@redhat.com 2016-04-07 22:27:27 UTC 
(In reply to Noriko Hosoi from comment #4)
> I think we need a doc bug if we haven't filed it...

I will file a doc bug when I have finished / acked the feature.
Comment 6 wibrown@redhat.com 2016-04-10 23:00:44 UTC 
Doc Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1325715
Comment 8 Viktor Ashirov 2016-06-08 15:10:42 UTC 
Build tested: 389-ds-base-1.3.5.4-1.el7.x86_64

# setfacl -m g:dirsrv:rwx /var/run/systemd/ask-password

[1] Starting using start-dirsrv/systemctl
 
# start-dirsrv 
Starting instance "qeos-106"
Enter PIN for Internal (Software) Token: ****************************************
[0 root@qeos-106 ~]# ss -ntpl  | grep ns-slapd 
LISTEN     0      128         :::389                     :::*                   users:(("ns-slapd",pid=2717,fd=6))
LISTEN     0      128         :::636                     :::*                   users:(("ns-slapd",pid=2717,fd=7))

[2] Starting manually

# /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-qeos-106 -i /var/run/dirsrv/slapd-qeos-106.pid -d 0
[08/Jun/2016:11:05:50.992369342 -0400] SSL alert: Sending pin request to SVRCore. You may need to run systemd-tty-ask-password-agent to provide the password.

Broadcast message from root.eng.rdu2.redhat.com (Wed 2016-06-08 11:05:50 EDT):

Password entry required for 'Enter PIN for Internal (Software) Token:' (PID 2827).
Please enter password with the systemd-tty-ask-password-agent tool!

On a second console:
# systemd-tty-ask-password-agent
Enter PIN for Internal (Software) Token: ****************************************

And then server starts up.
[08/Jun/2016:11:06:27.182694793 -0400] slapd started.  Listening on All Interfaces port 389 for LDAP requests
[08/Jun/2016:11:06:27.183931026 -0400] Listening on All Interfaces port 636 for LDAPS requests

Marking as VERIFIED.
Comment 11 Viktor Ashirov 2016-08-05 07:12:12 UTC 
With the new build server doesn't start, since /usr/sbin/ds_systemd_ask_password_acl is missing:

[root@rhel7ds ~]# systemctl status dirsrv
● dirsrv - 389 Directory Server rhel7ds.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Fri 2016-08-05 09:04:29 CEST; 10s ago
  Process: 6552 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=203/EXEC)

[root@rhel7ds ~]# file /usr/sbin/ds_systemd_ask_password_acl
/usr/sbin/ds_systemd_ask_password_acl: cannot open (No such file or directory)

Marking as ASSIGNED and TestBlocker.
Comment 13 Petr Vobornik 2016-08-05 14:35:10 UTC 
possible duplicates:

* bug 1364452 - installation of IPA
* bug 1364377 - installation of IPA
* bug 1364510 - upgrade of IPA
Comment 16 Viktor Ashirov 2016-08-08 03:50:55 UTC 
*** Bug 1364802 has been marked as a duplicate of this bug. ***
Comment 21 Kaleem 2016-08-09 13:07:15 UTC 
*** Bug 1364452 has been marked as a duplicate of this bug. ***
Comment 22 Scott Poore 2016-08-10 23:48:46 UTC 
*** Bug 1364510 has been marked as a duplicate of this bug. ***
Comment 23 Noriko Hosoi 2016-08-11 15:26:56 UTC 
*** Bug 1364377 has been marked as a duplicate of this bug. ***
Comment 25 Viktor Ashirov 2016-08-26 11:49:00 UTC 
Build tested: 389-ds-base-1.3.5.10-8.el7.x86_64

No manual workaround for systemd is needed, marking as VERIFIED.
Comment 37 errata-xmlrpc 2016-11-03 20:40:19 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.