[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Running slapd as a non-root user

On Wednesday 30 January 2008 23:01:07 Bill Sterns wrote:
> I'm currently running OpenLDAP 2.4.6 using SSL/TLS via OpenSSL 0.9.8b and
> Berkeley DB 4.6.21, which I built and installed from source as root. I'd
> like to be able to run slapd as a non-root user, as I've seen other
> packaged OpenLDAP distributions do in the past. However, when I try to run
> it as a non-root user, OpenLDAP does not have permission to access various
> things, such as slapd.conf, the back-end database files, and the directory
> to create its pid file when it starts up. I've tinkered with the file/group
> ownership and permissions for these files, and I've managed to get it
> running as a non-root user, but I'm not sure if this is the ideal way to do
> it. Is there a recommended way to do this?
> This is what I get when I initially try to run slapd as a non-root user:
> # /usr/local/libexec/slapd -d 256 -u openldap -h ldaps:///
> @(#) $OpenLDAP: slapd 2.4.6 (Jan 29 2008 18:42:36) $
>         bill@bill1:/home/bill/openldap-2.4.6/servers/slapd
> could not open config file "/usr/local/etc/openldap/slapd.conf": Permission
> denied (13) slapd stopped.
> connections_destroy: nothing to destroy.

Note, when starting as root with the -u flag, slapd opens ports before 
dropping privileges, so you can still run on the standard ports.

> Here's what I've done to run slapd as a non-root user:
> 1. Created user/group of openldap/openldap, put the openldap user in the
> openldap group 
> 2. Ran: chgrp openldap slapd.conf   # This was originally 
> owned by the group "other" 
> 3. Ran: chmod 640 slapd.conf         # This was 
> originally 600
> 4. Ran: chgrp -R openldap /usr/local/etc/openldap/certs      # Certs for
> SSL/TLS; originally owned by the group "other" 
> 5. Ran: chmod 440 
> /usr/local/etc/openldap/certs/host.key   # Private key for SSL/TLS;
> originally 400 

You don't indicate whether you ensure that the openldap user/group had rights 
to "enter" /usr/local/etc/openldap, most likely you need to do (at minimum):

chmod a+x /usr/local/etc/openldap

Note that you can very easily test component by component, by doing something 

# su - openldap -s /bin/bash
$ cd /usr/local/etc/openldap
$ head slapd.conf

(or similar)

(BTW, I consider this to really be basic Unix skills, not OpenLDAP-specific, 
or terribly advanced).

> 6. Ran: chgrp -R openldap /usr/local/var/openldap-data # 
> Back-end bdb; originally owned by the group "other" 7. Ran: chmod 775
> /usr/local/var/openldap-data   # Originally 755
> 8. Ran: chmod g+s /usr/local/var/openldap-data
> 8. Ran: chgrp openldap /usr/local/var/run    # Originally owned by the
> group "other" 9. Ran: chmod 775 /usr/local/var/run   # Originally 755
> 10. Ran: chmod 660 /usr/local/var/openldap-data/*   # Originally 600,
> except for alock 11. Ran: chmod 664 /usr/local/var/openldap-data/alock   #
> Originally 644
> After these steps, I can bring up OpenLDAP as my "openldap" user:
> # /usr/local/libexec/slapd -d 256 -u openldap -h ldaps:///
> @(#) $OpenLDAP: slapd 2.4.6 (Jan 29 2008 18:42:36) $
>         bill@bill1:/home/bill/openldap-2.4.6/servers/slapd
> bdb_monitor_open: monitoring disabled; configure monitor database to enable
> slapd starting
> Am I going about this the right way? Is running OpenLDAP as a non-root user
> a non-recommended thing to do when using an installation built from source?

There's no reason this should differ vs when installed from a package - I note 
that virtually all packages I have seen of OpenLDAP cater specifically to run 
as non-root (e.g., by default, run as non-root).

> And are there any other gotchas that might cause problems later?

No, just watch permissions, as always ...

> One 
> possible problem I can think of is if the database needs to be wiped and
> recreated from a backed-up LDIF file using slapadd; if slapadd is run as
> root, the permissions would have to be reset on the database files before
> slapd could start up.

which a single chown will fix.

> Any help would be greatly appreciated.