On Tue, Mar 1, 2011 at 8:30 PM, Iain M Conochie iain@shihad.org wrote:
Does ldap://XXXXX.XXXXXXXX.XXX have a port >= 1024 at the end ?
Nope
If default of 389, must be root to listen.
Interesting....
ps -ef |grep slapd ldap 30749 1 0 10:23 ? 00:00:00 /opt/openldap/libexec/slapd -u ldap -g ldap -h ldap://XXXX02.XXXXXX.org ldaps://XXXX02.XXXXXX.org
netstat -anlp|grep slapd tcp 0 0 192.168.1.36:389 0.0.0.0:* LISTEN 30749/slapd tcp 0 0 192.168.1.36:636 0.0.0.0:* LISTEN 30749/slapd
This is with version 2.4.13, which as you can see is running as user ldap and bound to 2 ports < 1024
A process that starts as root can choose to give up it's root permission after binding the privileged port, and switch to a given userid/group. I presume slapd switches to user "ldap", you don't need to be privileged to accept connections once the privileged listening socket has been bound by root.
Yup
As a security feature, once the process gives up root permissions, it cannot get them back, but it can still use the socket previously bound by root as it keeps a reference to the socket so it can listen on it for connections.
Naturally. The reason I want to run slapd as user "ldap" is for this reason. If I do not have to run something as root I do not :)
So slapd is able to start and bind to the port. I though this used a mechanism like that of apache whereby the daemon starts as root and then binds to the ports, then drops the privileges to the non-root user, or am I missing something?
Nope. Apache needs to start as root if listen port <1024, it then gives up it's permission for the worker threads that actually do the work. The session leader still runs as root, but it does not do any actual work but manage the non-root children.
<snip some very useful info I will look at later>
Well - I have managed to get 2.4.23 working starting as root and using the -g and -u options to actually run as user ldap. 2.4.24 was NOT able to do that giving the error above. Since I have a working version now I am pretty happy.
However the error that 2.4.24 gives seems bizarre. I can do more testing on this if you want further info; perhaps slapd is unable to find the user ldap?
Thanks for your help
Cheers
Iain
Cheers Brett