Re: [Devel] race condition when creating ldap entries

[Andreas Schuldei <andreas@xxxxxxxxxxxx>]

* Harald Thingelstad (harald@xxxxxxxxxxxxx) [030801 19:03]:
> A note from someone who can't keep his paws off..
> 
> fredag 1. august 2003, 17:35, skrev Andreas Schuldei:
> > as i understand it we have no protection against race conditions
> > in the ldap code.
> ...
> > we have several options to solve this problem:
> >
> > use a database with transaction support (postgresql is my
> > favourit) and rollback doing the user management. This is the way
> > *real* systems like sourceforge and alioth are doing it. (c:
> > ldap is just used as a fast lookup, not as the real backend.
> 
> Old itch, this one. So far we've just lived with it and demanded no parallell 
> submissions. Is this a critical demand?
> 
> The problem with postgresql is getting it to install smoothly. See bug #22 
> (recently translated to English).
> On the other hand, some user index is going to be needed in postgresql 
> (default Skolelinux DBMS) sooner or later anyway. 

good. that would be the way to go, then.

> To help other applications 
> going. Like class management systems and the likes. (National level systems 
> are slow and clunky, when all users massively tries to use it with the 
> schools "broadband"..) 
> Or, should the cups/pyqota page counter be managed in LDAP?

yes, even without race conditions, i think, since incrementing a
number is save in ldap. 

> > have one "uid-daemon" doing all the (sequential) ldap write
> > queries (and also uid and login creation), which he receives from
> > the webmin instances, nicely queued through a pipe.
> 
> Could get difficult to secure? See the Cups vulnerability.
> http://lwn.net/Vulnerabilities/33772/

uh, that is not an issue. i have done a similar deamon: just make
the pipe read/writeable by root only. and send atomic requests,
like: "create a user with these attributes, NOW." No request that
could time out, no DOS.