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.
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 messy.
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.
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.
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 messy.
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 specified user/group/root.
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?
Kurt
Kurt D. Zeilenga wrote:
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 specified user/group/root.
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?
I was only talking about user and group and listeners, I would leave root on the command line. As for when they take effect, we'd require that they get issued before any backend or database directives. With back-config they would be in the global section and naturally execute before anything else.
--On Thursday, October 26, 2006 2:24 PM -0700 Howard Chu hyc@symas.com wrote:
Kurt D. Zeilenga wrote:
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 specified user/group/root.
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?
I was only talking about user and group and listeners, I would leave root on the command line. As for when they take effect, we'd require that they get issued before any backend or database directives. With back-config they would be in the global section and naturally execute before anything else.
So with Howard's clarification, is there still objection?
In the meantime, in the 2.3 release, it may be worthwhile to note something in the man pages, like:
--- openldap-old/doc/man/man8/slapindex.8 2006-01-03 23:16:06.000000000 +0100 +++ openldap2.3-2.3.27/doc/man/man8/slapindex.8 2006-10-24 20:21:16.000000000 +0200 @@ -90,6 +90,10 @@ should not be running (at least, not in read-write mode) when you do this to ensure consistency of the database. .LP +slapindex ought to be run as the same user that +.BR slapd (8) +uses to ensure correct database permissions. +.LP This command provides ample opportunity for the user to obtain and drink their favorite beverage. .SH EXAMPLES
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
-
Howard Chu -
Kurt D. Zeilenga -
Quanah Gibson-Mount