[Date Prev][Date Next]
Quanah Gibson-Mount wrote:
--On Monday, February 21, 2005 9:13 AM -0800 Howard Chu
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
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
Symas: Premier OpenSource Development and Support