Hello
Right now, slapd ignore attribute ACL when performing an add
operation.
If you have privilegied users that can add entries, it means that you
can
prevent them from modifying attributes in existing entries, but you
cannot
prevent them from adding an entry with a read-only attribute.
The problem can be interesting with an attribute such as authzTo,
where the
whole access control can be circumvented by any user that can create
an
entry in the tree. IMO this behavior was not intended, but if it was,
then
it should be clearly documented.
Below is a patch that cause attribute ACL to be checked for add
operations.
It is done in the backend, so if it is acceptable, then I will have to
do it
for other backends. I wonder if the modrdn operation shoulnd't be
subject to
the same sanity checks.
Any thought? Does it look right?
diff -U2 -r1.174 add.c
--- servers/slapd/back-bdb/add.c 26 Aug 2008 23:45:35 -0000
1.174
+++ servers/slapd/back-bdb/add.c 27 Sep 2008 15:54:58 -0000
@@ -300,4 +300,22 @@
}
+ /*
+ * Check ACL for attribute write access
+ */
+ if (!acl_check_modlist(op, oe, op->ora_modlist)) {
+ switch( opinfo.boi_err ) {
+ case DB_LOCK_DEADLOCK:
+ case DB_LOCK_NOTGRANTED:
+ goto retry;
+ }
+
+ Debug( LDAP_DEBUG_TRACE,
+ LDAP_XSTRING(bdb_add) ": no write access to
attribute\n",
+ 0, 0, 0 );
+ rs->sr_err = LDAP_INSUFFICIENT_ACCESS;
+ rs->sr_text = "no write access to attribute";
+ goto return_results;;
+ }
+
if ( eid == NOID ) {
rs->sr_err = bdb_next_id( op->o_bd, &eid );
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
See ITS#4556 for discussion.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------