netdev - Re: why would EPIPE cause socket port to change?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0701232202320.27405@twinlark.arctic.org>
Date:	Tue, 23 Jan 2007 22:09:28 -0800 (PST)
From:	dean gaudet <dean@...tic.org>
To:	David Miller <davem@...emloft.net>
cc:	rick.jones2@...com, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org
Subject: Re: why would EPIPE cause socket port to change?

On Tue, 23 Jan 2007, David Miller wrote:

> From: dean gaudet <dean@...tic.org>
> Date: Tue, 23 Jan 2007 12:11:01 -0800 (PST)
> 
> > libnss-ldap has some code which attempts to determine if its private 
> > socket has been trampled on in between calls to the library... and to do 
> > this it caches getsockname/getpeername results and compares them every 
> > time the library is re-entered... and when there's a mismatch it leaks a 
> > socket (eventually crashing nscd if you're using that).  i've been trying 
> > to band-aid over the problem:
> > 
> > http://bugzilla.padl.com/show_bug.cgi?id=304
> > http://bugzilla.padl.com/show_bug.cgi?id=305
> > 
> > but i'm probably going to need to approach it from another direction -- 
> > make libnss-ldap monitor the ldap library results so it knows when there's 
> > been a read/write error so that it stops doing this 
> > getsockname/getpeername thing after the error has occured.
> 
> Please do not write programs in this way.  getsockname/getpeername
> were never meant to be used in that way, and it's hella inefficient
> to keep checking the socket like that to boot.
> 
> I really don't see you gaining anything by making this check every
> time the user calls into the library.
> 
> If the application mucks with the communications channel socket, so
> what, it's his application that will go tits up.
> 
> Is there some tricky interaction between nscd and something like
> libnss-ldap that makes this tom-foolery necessary?
> 

oh heck yeah i totally agree -- it's not my code though, i'm just 
debugging it.

-dean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html