Re: back-sql insert: entry at root denied

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

Brad Midgley wrote:

> Pierangelo
>
> I was hoping to preserve the view. The data is being changed by sybase 
> clients and I'd need to set up the appropriate triggers to update it. 
> That is an option I'll consider though.
>
> This version of sybase does not support union in a view. I already 
> looked down that avenue. 

This would be the most appropriate way to handle this type of configuration.

> From reading the code, I started to think it was possible to do 
> without the parent in the db. The suffix entry is not found, but down 
> later in that section of code is
>
> if ( ( ( !be_isroot( op ) && !be_shadow_update( op ) )
>  || !BER_BVISEMPTY( &pdn ) ) && !is_entry_glue( op->oq_add.rs_e ) )
> { ... } else {
>     parent_id.eid_id = 0;
> }

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).

> So I was thinking I could coax it to take that branch and assume the 
> parent has the id 0 even though it wasn't found. Does this approach 
> have implications that make it too messy or painful?

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).

> I have insentry_query set to "" in my config. I could test for that 
> empty value if necessary when handling add or modrdn. Or I could set 
> insentry_query to some kind of no-op that accepts four parameters, but 
> I certainly prefer to have any patches I make accepted upstream. I 
> don't think you'd want the blind assumption that if the parent isn't 
> found we can just use an id of 0. 

I guess SQLPrepare()ing and SQLBindParameter()ing with respect to an 
empty string may not be a Good Thing, but as long as your RDBMS doesn't 
complain that should be fine.

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...

p.



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