Re: ldapi PATH oddity

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

Rich Graves wrote:

> openldap 2.2.14 on Linux RedHat Enterprise 3.
>
> I'm doing anonymous simple binds over ldapi:///. On my test machine, 
> everything including an ACL based on peername.path="/var/run/ldapi" work.
>
> When I moved it to a production machine, the ACL failed, and logs show 
> gibberish IPC PATH like the below.
>
> As far as I can tell, the only difference between the machines is that the
> production machine has multiple CPUs. The running binaries, slapd.conf, and
> kernel versions seem to be the same.
>
> Jul 29 14:26:38 blanca slapd[22123]: conn=141 fd=19 ACCEPT from PATH=§o\201@c£ (PATH=/var/run/ldapi)
> Jul 29 14:28:07 blanca slapd[22123]: conn=157 fd=10 ACCEPT from PATH=¨$\201@c£ (PATH=/var/run/ldapi)
> Jul 29 14:51:41 blanca slapd[22123]: conn=466 fd=10 ACCEPT from PATH=´;\201@c£ (PATH=/var/run/ldapi)
> Jul 29 15:14:46 blanca slapd[22123]: conn=805 fd=21 ACCEPT from PATH=À®\201@c£ (PATH=/var/run/ldapi)
> Jul 29 15:14:51 blanca slapd[22123]: conn=807 fd=22 ACCEPT from PATH=À¹\201@c£ (PATH=/var/run/ldapi)
> Jul 29 15:18:33 blanca slapd[22351]: conn=3 fd=10 ACCEPT from PATH=Âç\201@c£ (PATH=/var/run/ldapi)
>  
Quoting from servers/slapd/daemon.c, this is where the string
you're seeing should be filled:

       case AF_LOCAL:
               /* FIXME: apparently accept doesn't fill
                * the sun_path sun_path member */
               if ( from.sa_un_addr.sun_path[0] == '\0' ) {
                       AC_MEMCPY( from.sa_un_addr.sun_path,
                                       
slap_listeners[l]->sl_sa.sa_un_addr.sun_path,
                                       sizeof( from.sa_un_addr.sun_path 
) );
               }

               sprintf( peername, "PATH=%s", from.sa_un_addr.sun_path );

I think I fixed the problem and wrote the comment, but I don't
remember the details.  Apparently, the string that should contain
the path of the socket that is connecting is not filled by accept();
this should be harmless, since it's supposed to be exactly the same
as the PATH of the listener.
If the problem is safely detected, i.e. the buffer starts with '\0',
the string in the listener is used.  Apparently, in your production
machine, no safe detection can occur, because the path is garbage
but doesn't start with '\0'.  I/m not expert enough of socket
programming to determine if this behavior is corret or represents
a bug in the libc, and if there's a cleaner workaround.  Note that
the second "PATH=%s" between brackets shows the string as stored
in the listener's structure, which should be the same as the screwed
one.  Unfortunately, since the "sun_path" member is a static buffer
and not a pointer, there's little way to see if it's been correctly
filled or not; of course we could check if it contains a valid path,
but I think this would be slightly overkill.

p.





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