[Date Prev][Date Next]
--On Monday, February 21, 2005 10:39 AM -0800 Howard Chu <firstname.lastname@example.org>
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
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.
But I have no intention of ever defining a root password on any of my
systems, as it violates Stanford's security policies. There is a reason
its directory service is entirely password free. I suppose if I can use a
group as the rootdn, and have the rootdn authenticated via SASL/GSSAPI,
that would suffice, since I have an ldap administrator group that is given
write access based off the SASL/GSSAPI mappings.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin