FS#25168 - [openldap] slapd can no longer run as non-root with pidfile in /run

Attached to Project: Arch Linux
Opened by Geert Hendrickx (ghen) - Tuesday, 19 July 2011, 09:16 GMT
Last edited by Eric Belanger (Snowman) - Thursday, 21 July 2011, 19:26 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Eric Belanger (Snowman)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Since moving the pidfile from /var/lib/openldap/run to /run, slapd can no longer run as a non-root user:

unable to open pid file "/run/slapd.pid": 13 (Permission denied)

(when running with -u ldap -d -1)

This is probably more of an issue with slapd dropping privileges too early, but it worked before with the pidfile in a dedicated (ldap owned) directory. Or should /run be 1777 like /tmp?
This task depends upon

Closed by  Eric Belanger (Snowman)
Thursday, 21 July 2011, 19:26 GMT
Reason for closing:  Implemented
Additional comments about closing:  daemon now runs as ldap user and group.
Comment by Geert Hendrickx (ghen) - Tuesday, 19 July 2011, 09:28 GMT
Perhaps the rc.d script should create a /run/ldap subdir, like several other daemons do, and do its business there instead? (pidfile, argsfile, socket)
Comment by Eric Belanger (Snowman) - Tuesday, 19 July 2011, 20:14 GMT
The previous package had the pid file in /var/run/ which is also only writable by root. Are you sure that you could run it in the old package as non-root? The daemon script start it as root user.

If you edit the values of pidfile and argsfile in /etc/openldap/slapd.conf to have the files in /var/run or another directory, does it work?
Comment by Geert Hendrickx (ghen) - Wednesday, 20 July 2011, 06:50 GMT
Yes, putting them in another directory (together with the ldapi:// socket) works, and that's what I'm doing now.

slapd runs fine as a non-root user in general, if you give config files (640 root:ldap) and databases (ldap:ldap all the way) the proper permissions. I think it should be considered to make it run that way by default on Arch. There is no real reason to run it as root.
Comment by Eric Belanger (Snowman) - Wednesday, 20 July 2011, 20:03 GMT
Of course, if you change all the permissions, then it will run as non-root as long as your user is in the ldap group. Technically, the current package in testing works fine as it's intended to be run as root. This bug report is more like a feature request for running the daemon as another system user than root. I'll need to look into it. I know that Debian run slapd as an openldap user so there might be an advantage in doing so.
Comment by Eric Belanger (Snowman) - Thursday, 21 July 2011, 04:33 GMT
Implemented in openldap-2.4.26-2 in testing. Please test it and let me know how it goes.
Comment by Geert Hendrickx (ghen) - Thursday, 21 July 2011, 09:36 GMT
Works fine, but with two remarks:

- install /run/openldap should be moved to the rc.d script instead of the package_openldap() target,
- libldap should be rebuilt as well for the new ldapi socket path (I edited /etc/openldap/ldap.conf for now).

PS: you can install(1) with -o/-g to set owner/group instead of the additional chown.
Comment by Eric Belanger (Snowman) - Thursday, 21 July 2011, 17:08 GMT
- install /run/openldap should be moved to the rc.d script instead of the package_openldap() target,

I thought about it but the packages were already built and tested so I decided to leave it. I'll change it in svn.

- libldap should be rebuilt as well for the new ldapi socket path (I edited /etc/openldap/ldap.conf for now).

Are you sure you have libldap 2.4.26-2 installed? Here it has the correct reference:
$ strings /usr/lib/libldap-2.4.so.2 |grep ldapi
ldap_is_ldapi_url
ldapi://
/run/openldap/ldapi

If you get different output, paste it here. Also, put steps to reproduce the problem as well as the change you did to the config file to fix it.
Comment by Geert Hendrickx (ghen) - Thursday, 21 July 2011, 17:52 GMT
Sorry, I didn't upgrade libldap. It's ok indeed.

Thanks!

Loading...