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

Re: acl entry causes segfault



Markus Krause wrote:
Zitat von Pierangelo Masarati <ando@sys-net.it>:

Markus Krause wrote:
Hi list!

i am using OpenLDAP 2.3.34-5.2 on a SLES10 server.
in my LDAP database i am using the attribute "description" in some cases
to store information which i do not want to be readable by everyone. to
prevent it for all users but "admin" is use the following acl entry in
slapd.conf:
---- slapd.conf
access to attrs=description
        by dn="cn=Admin,o=test" write
        by group.exact="cn=Admingroup,ou=ACL,o=test" write
        by * none
---- slapd.conf
this works but denies access to all but admin and members of group
admingroup.

the i tried to set the following acl which should only deny access to
the description field in a subtree:
---- slapd.conf
access to dn.subtree="ou=people,o=test" attrs=description
        by dn="cn=Admin,o=test" write
        by group.exact="cn=Admingroup,o=test" write
        by * none
---- slapd.conf

this leads to a segmentation fault, the last lines of the debug output is:
--- slapd -d 65535
config_build_entry: "cn={9}misc"
config_build_entry: "olcDatabase={-1}frontend"
Segmentation fault
---
so i obviously am doing something very wrong!


how can i allow or deny access to some attributes in a specific subtree?

thanks in advance for any hints!

You don't provide enough info to determine what's wrong. You should
provide a stack backtrace (make sure you use a slapd compiled with
debugging symbols and not stripped) and a complete (sanitized) slapd.conf.

ok, here you are: ---- cleaned slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/dhcp.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/freeradius.schema include /etc/openldap/schema/misc.schema

pidfile        /var/run/slapd/slapd.pid
argsfile    /var/run/slapd/slapd.args

modulepath    /usr/lib/openldap/modules
moduleload    smbk5pwd.so

sizelimit unlimited

access to attrs=SambaLMPassword,SambaNTPassword
    by dn="cn=Manager,dc=biochem,dc=mpg,dc=de" write
    by group.exact="cn=LDAP Managers,ou=ACL,dc=biochem,dc=mpg,dc=de" write
    by dn="cn=Samba,ou=ACL,dc=biochem,dc=mpg,dc=de" read
    by * none

access to dn.base=""
by dn="cn=Manager,dc=biochem,dc=mpg,dc=de" write
by group.exact="cn=LDAP Managers,ou=ACL,dc=biochem,dc=mpg,dc=de" write
by * read


access to dn.base="cn=Subschema"
by dn="cn=Manager,dc=biochem,dc=mpg,dc=de" write
by group.exact="cn=LDAP Managers,ou=ACL,dc=biochem,dc=mpg,dc=de" write
by * read


access to attrs=userPassword,userPKCS12
by dn="cn=Manager,dc=biochem,dc=mpg,dc=de" write
by group.exact="cn=LDAP Managers,ou=ACL,dc=biochem,dc=mpg,dc=de" write
by self write
by * auth


access to attrs=shadowLastChange
by dn="cn=Manager,dc=biochem,dc=mpg,dc=de" write
by group.exact="cn=LDAP Managers,ou=ACL,dc=biochem,dc=mpg,dc=de" write
by self write
by * read


access to dn.subtree="ou=people,dc=biochem,dc=mpg,dc=de" attrs=description
by dn="cn=Manager,dc=biochem,dc=mpg,dc=de" write
by group.exact="cn=LDAP Managers,ou=ACL,dc=biochem,dc=mpg,dc=de" write
by * none


access to *
by dn="cn=Manager,dc=biochem,dc=mpg,dc=de" write
by group.exact="cn=LDAP Managers,ou=ACL,dc=biochem,dc=mpg,dc=de" write
by * read


loglevel 0
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /etc/ssl/servercerts/servercert.pem
TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem
TLSCACertificateFile /etc/ssl/mpibc-w2k_root-ca.pem
database bdb
suffix "dc=biochem,dc=mpg,dc=de"
rootdn "cn=Manager,dc=biochem,dc=mpg,dc=de"
rootpw "{ssha}XXXX"
overlay smbk5pwd
smbk5pwd-enable samba

The directives below appear __after__ an overlay instantiation, while they belong to the database. Intermixing database and overlay directive is known to lead to undefined results (a crash is just a clear sign of error, but what basically happens is that overlay parsing code mucks with database private memory and vice versa). Pease re-sort your configuration to clearly confine each database directive right after the database instantiation, and each overlay's directive right after that overlay instantiation and before any subsequent overlay instantiation. This should fix your problem.


p.

directory /var/lib/ldap/
checkpoint 1024 5
cachesize 10000
index objectClass,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq
index entryCSN,entryUUID eq
index dhcpHWAddress eq,pres
index relativeDomainName eq,pres
index ipHostNumber eq,pres
index zoneName eq,pres
index radiusGroupName eq,pres
index description eq,sub,pres

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

---- end of slapd.conf




Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------