Re: back-sql insert: entry at root denied

[Pierangelo Masarati <ando@sys-net.it>]

Pierangelo Masarati wrote:

> The meaning of this test is: "adding an entry without a parent is 
> something very special", so it has to be possible only for special 
> users or in special circumstances.  I undrestand back-sql is all 
> special, so I wouldn't mind a configure option that says: "let 
> everybody add entries without a parent" (of course provided ACLs grant 
> them entry write access). Someting like
>
>    allow_orphans    {NO|yes}
>
> so that the test would become
>
>    if ( ( ( !be_isroot( op ) && !be_shadow_update( op ) )
>        || !BER_BVISEMPTY( &pdn ) ) && !is_entry_glue( op->oq_add.rs_e 
> ) && !bi->bi_allow_orphans )
>    { ... } else {                                                    
> /* ^^^^^^^^^^^^^^^^^^^^^^^^ */
>        parent_id.eid_id = 0;
>    }
>
> also, an empty insentry_query should mean that no modifications of the 
> ldap_entries table should be attempted (sort of implying that a view 
> is used, or a trigger for modifications at the RDBMS side is in place).

Just committed this to HEAD; I won't add it to RE22 unless it proves useful.

> The main implication is that you'd be allowed to create orphaned 
> entries, i.e. entries without a "real" parent, just rooted at 
> somewhere that does not exist, or, even worse, that exists, but it's 
> not exactly one level above in the tree structure.  I also note that 
> another drawback of not having a real entry for the database suffix is 
> that the search optimizations that I'm working at will  break the 
> current behavior, i.e. subtree searches will require the search base 
> to exist. I guess right now you can search your database even if the 
> suffix entry does not exist (but you cannot do onelevel searches).  
> This is going to be no longer possible shortly (in HEAD; perhaps a bit 
> later in RE22).

Just committed this as well.  Now the base object of a search needs to 
exist.

> Another approach I'm considering, based on the usage many people I 
> assume are doing of back-sql, is to provide a "fake" in-memory suffix 
> entry, with the rest of the database being flat and based on a single 
> view for the rest of the entries.  Something much like the good old 
> back-passwd...

I'll put this on the "short back-sql todo list" for view users... in the 
meanwhile, I suggest not to use HEAD code, or subtree searches with 
nonexisting baseobject will fail.

p.





   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497