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

re: back-config

Quanah Gibson-Mount wrote:

--On Monday, February 21, 2005 9:13 AM -0800 Howard Chu <hyc@symas.com> wrote:

On the subject of hierarchical configuration directives - you can start
looking at the behavior of back-config. It's still extremely incomplete.
If you want to see what's currently visible, add
   database config
   rootpw <something>
to your slapd.conf; the suffix and rootdn are hardcoded to "cn=config".

There is no write/modify support here yet. It's taking a long time just
to implement all of the read support...


Hm, this actually brings up an interesting point -- How do you handle updating replica's vs. masters? And what about other auth mechanisms instead of using a rootpw?

For item #1:

My master's slapd.conf is very different from the slapd.conf on the replica's, as it has minimal indexing, and a completely different set of ACL's. How am I supposed to make modifications to the replica's configuration? I have to assume that the back-config DB is never a candidate for replication? In that case, it will be a pain to make updates to the replica's, as you'll have to modify every single one individually. If not, then do we have multiple back-config directives, one per system, residing on the master, so that when a modification is made to the master for a particular replica, it'll propagate the changes to that particular replica? Or do we now require that the master & replica always match in configuration?

You seem to think that "master" and "replica" applies to an entire server, but the concepts only apply to individual databases. As such, what you do wrt replication of cn=config is totally a local policy issue.

For item #2:

I don't have any rootpw defined in any of my systems, as I use SASL/GSSAPI authentication for all write-related activity. I assume for the back-config stuff then, it will be possible to define an ACL saying what principal can write to that DB? Or a configuration directive?

Currently I have no plans to allow any other users to access this DB. This is after all very sensitive material; once you have the ability to make runtime configuration changes on the fly you also have the ability to royally screw things up on the fly. So for now it's rootdn only, and no possibility of defining ACLs.

Historically, few (no?) X.500 servers have allowed protocol access to access control rules. It may be inconvenient, but the restriction is logical from a security standpoint - allowing such access opens you up to a huge universe of vulnerabilities previously unseen. And as a practical matter, it makes no sense to be forced to look inside an object to read the rules that tell you if you're allowed to look inside the object. There are a number of chicken-and-egg problems there.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support