Bug 1316580 - dirsrv service doesn't ask for pin when pin.txt is missing
dirsrv service doesn't ask for pin when pin.txt is missing
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.2
Unspecified Unspecified
urgent Severity urgent
: rc
: ---
Assigned To: wibrown@redhat.com
Viktor Ashirov
Petr Bokoc
: Regression, TestBlocker
: 1364377 1364452 1364510 1364802 (view as bug list)
Depends On: 1322167 1324983
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-10 09:16 EST by Viktor Ashirov
Modified: 2017-07-31 04:09 EDT (History)
12 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 16:40:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker 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 08:11:08 EDT

  None (edit)
Description Viktor Ashirov 2016-03-10 09:16:45 EST
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@rhel7ds.service
3. systemctl status dirsrv@rhel7ds.service -l

Actual results:
[root@rhel7ds ~]# systemctl status dirsrv@rhel7ds.service -l
● dirsrv@rhel7ds.service - 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 15:31:55 EST
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 15:53:30 EDT
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@SERV_ID.service
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 18:27:27 EDT
(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 19:00:44 EDT
Doc Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1325715
Comment 8 Viktor Ashirov 2016-06-08 11:10:42 EDT
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@qeos-106.lab.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 03:12:12 EDT
With the new build server doesn't start, since /usr/sbin/ds_systemd_ask_password_acl is missing:

[root@rhel7ds ~]# systemctl status dirsrv@rhel7ds.servicedirsrv@rhel7ds.service - 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 10:35:10 EDT
possible duplicates:

* bug 1364452 - installation of IPA
* bug 1364377 - installation of IPA
* bug 1364510 - upgrade of IPA
Comment 16 Viktor Ashirov 2016-08-07 23:50:55 EDT
*** Bug 1364802 has been marked as a duplicate of this bug. ***
Comment 21 Kaleem 2016-08-09 09:07:15 EDT
*** Bug 1364452 has been marked as a duplicate of this bug. ***
Comment 22 Scott Poore 2016-08-10 19:48:46 EDT
*** Bug 1364510 has been marked as a duplicate of this bug. ***
Comment 23 Noriko Hosoi 2016-08-11 11:26:56 EDT
*** Bug 1364377 has been marked as a duplicate of this bug. ***
Comment 25 Viktor Ashirov 2016-08-26 07:49:00 EDT
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 16:40:19 EDT
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.