At 01:32 PM 10/26/2006, Howard Chu wrote:
I was reviewing the discussion of ITS#4719 and thinking about some of
the options. We could add a setuser/setgroup config directive for the tools to use. It
might be confusing since these directives would not replace the need for slapd's -u
and -g commandline options.
I think we should avoid setuser/setgroup configuration directives.
(I have less problem adding -u/-g/-r to tools).
Along those lines, how does anyone use slapd with the -r option? Since
no corresponding option exists for the tools, and presumably the pathnames in slapd.conf
are absolute paths, I guess you would need an alternate config for running the tools
outside the chroot jail, with the full paths to the jailed directories. Seems rather
One just needs make sure that the paths inside and outside the jail
are the same (using symlinks as needed). I do this for all my jails
so I don't have to chroot(8)/jail(8) to admin.
I would expect the more common scenario is to just run slapd using a
userID that doesn't have write privileges outside its database directories, and not
worry about a chroot jail.
I actually use jail(8) instead of -r. For this, one uses a startup
script which starts the jail first. Only minor hitch here is making
sure the ldapi socket (created inside the jail) is usable outside
the jail... but as in the above, a job for a symlink.
We've talked about this in the past - why don't we restructure
things so that the user and group are read from the config, along with the listeners?
I.e., defer dropping root privs until after the config has been read.
Personally, I prefer our current approach. Everything on the
command line is done from the user/group/root of the parent,
everything in the config file is done from the command line
Placing user/group/root in the config file makes it confused
as to what is processed under which user/group/root. For
instance, in a custom backend with custom directives, would
these be processed before or after the change?