Dai test che ho fatto a me sembra l'esatto contrario, ovvero mi applica
le acl del database anche quando il pattern non dovrebbe "matchare"
poiché al di fuori del database.
Esempio:
Voglio che il rootDSE sia leggibile da tutti (utenti e anonimi) anche
senza alcun livello di crittografia (ssl/tls), quindi impongo le
seguenti acl:
# Queste sono le regole che mi hai suggerito e che inserisco in testa
# alle altre acl.
# Mi segnalano un warning (che ignoro allegramente) relativo al contesto
# ovunque le posiziono e la loro posizione (prima o dopo la direttiva
# database) è ininfluente per il risultato.
access to dn="" by * read
access to dn="cn=subschema" by * read
# In terza posizione imposto l'acl che imponga il tls/ssl per le
# connessioni ad uno specifico db attraverso l'interfaccia
# pubblica (NB: l'interfaccia privata è collegata alla rete
# 192.168.1.0/24):
access to dn.subtree="dc=example,dc=com"
by peername.ip=192.168.1.0%255.255.255.0 break
by peername.ip=0.0.0.0%0.0.0.0 ssf=128 break
by * none
Secondo quello che sapevo con queste acl in questa sequenza se io faccio
la seguente query:
ldapsearch -LLL -x -D 'cn=admin,dc=example,dc=com' -W -h $IP_PUBBLICO \
-b '' -s base '(objectClass=*)' namingContexts
dovrei avere il seguente risultato:
dn:
namingContexts: dc=example,dc=com
Ed invece ricevo un errore di violazione di una acl:
ldap_bind: Invalid credentials (49)
Sul log del server (a cui ho impostato il livello di debug ad acl)
leggo:
=> acl_mask: to value by "", (=0)
<= check a_peername_path: 192.168.1.0%255.255.255.0
<= check a_peername_path: 0.0.0.0%0.0.0.0
<= check a_authz.sai_ssf: ACL 128 > OP 0
<= check a_dn_pat: *
<= acl_mask: [5] applying none(=0) (stop)
<= acl_mask: [5] mask: none(=0)
=> slap_access_allowed: auth access denied by none(=0)
=> access_allowed: no more rules
Mi sembra che non prenda in considerazione le prime due ACL.
Inoltre il match con "dc=example,dc=com" mi sembra totalmente errato.
Com'è possibile?
Ho testato e ricontrollato tutto molte volte no esistono altre acl oltre
a quelle che vi ho esposto.
Come posso fare?
Il giorno mar, 12/05/2009 alle 09.36 +0200, Pierangelo Masarati ha
scritto:
> Michele Codutti wrote:
>
> > Comunque grazie all'impostazione del debuglevel a acl ho scoperto quali
> > sono le regole che mi creano il problema:
> > access to *
> > by peername.ip=192.168.1.0%255.255.255.0 break
> > by peername.ip=0.0.0.0%0.0.0.0 ssf=128 break
> > by peername.ip=0.0.0.0%0.0.0.0 stop
> > by * break
> > Queste regole erano state impostate grazie ad un suggerimento richiesto
> > in questa ML:
> > http://www.sys-net.it/pipermail/openldap/2007-September/000736.html
> > Servivano per imporre la cifratura per le connessioni in arrivo
> > dall'interfaccia pubblica.
> >
> > Mi ricordo che qualcosa relativamente alle ACL era cambiato ma adesso
> > non riesco a trovare più quell'informazione mi sapete fornire qualche
> > indicazione?
>
> Se non sbaglio, quello che essenzialmente e' cambiato e' che mentre
> prima in assenza di ACL globali per l'accesso a dati globali come
> rootDSE e affini venivano usate le ACL del primo database, ora non piu'.
>
> Ciao, p.
>
>
> 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
> Fax: +39 0382 476497
> Email: a...@sys-net.it
> -----------------------------------
>
>
--
Michele Codutti
Centro Servizi Informatici e Telematici (CSIT)
Universita' degli Studi di Udine
via Delle Scienze, 208 - 33100 UDINE
tel +39 0432 558928
fax +39 0432 558911
e-mail: michele.codutti at uniud.it
_______________________________________________
OpenLDAP mailing list
OpenLDAP@mail.sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap
