High network usage on system using ldap authentication

[GoogleCodeExporter]

When the system is configured to use LDAP for user authentication and as
user base, then socksent-service is continuously exchanging high amount of
the data with ldap server.

Original issue reported on code.google.com by mirekm...@gmail.com on 1 Apr 2010 at 2:54

[GoogleCodeExporter]

Is your LDAP server also your DNS server? If so, this is expected behavior if 
you've
enabled host name lookups. Socket Sentry does not initiate traffic with any 
server
other than the DNS server. (And even those results are cached.)

Original comment by rhasselb...@gmail.com on 1 Apr 2010 at 3:11

[GoogleCodeExporter]

Marking INVALID on assumption that this is really DNS traffic, since SS doesn't
participate in any other kind of traffic. To eliminate DNS queries, host name 
lookups
should be disabled (the default).

Original comment by rhasselb...@gmail.com on 1 Apr 2010 at 6:27

• Changed state: Invalid

[GoogleCodeExporter]

No it is not.
I dumped packets exchaged between socksent-service and ldap server, and it 
seems, that
the service is asking for user using kde before each refreshing of applet data. 
I
thing that the user info, should be saved somewhere once access is granted.

Original comment by mirekm...@gmail.com on 2 Apr 2010 at 7:48

[GoogleCodeExporter]

Ahh, OK, this is because SS is asking libc to supply the owner of each process 
and on
machines that use LDAP, this must be causing a network round trip. I'll have to 
see
if there's another way to get (or at least cache) this data.

Original comment by rhasselb...@gmail.com on 2 Apr 2010 at 1:36

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by rhasselb...@gmail.com on 2 Apr 2010 at 1:37

[GoogleCodeExporter]

Upgrading to high. Should try to resolve in the next point release.

Original comment by rhasselb...@gmail.com on 2 Apr 2010 at 1:45

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Couldn't find anything in /proc. The "ps" command uses the same libc call. The 
"top"
command does, as well, but it has a cache. I suppose that's the way to go, even
though I intended for SS to maintain radio silence unless host lookups was 
turned on.

Original comment by rhasselb...@gmail.com on 4 Apr 2010 at 12:28

• Changed state: Started

[GoogleCodeExporter]

Fixed in revs f5905277f9 and 1e4c345d27 to land in release 0.9.2. SS now 
performs
process owner username lookups asynchronously and caches the results.

Original comment by rhasselb...@gmail.com on 6 Apr 2010 at 12:18

• Changed state: Fixed

[GoogleCodeExporter]

I found the reason of the bug. There were two things together.
One of them was crash of nscd, there is bug in glibc since about 3 years, that 
is
not corrected until now. Now I switched to unscd, and it solves problem of big 
data
exchange.
But from the side of socketsentry there is still an issue. If nscd is not 
running,
socketsentry ask ldap for user/group of each task accessing the network. Once it
started asking the ldap, it access the network by itself, and asks for username 
of
socksent-service, and then it is going to endless loop. If all other jobs don't
connect the network, socksent-service do, becuase it asks for the user assigned 
to
itself.

Since unscd daemon is running, this problem don't disturb me as well. So if you
like, you could change this behavior (so the socksent-service remember 
association
of user and group to itself).

Anyway Thank you very much for good job.

Original comment by mirekm...@gmail.com on 7 Apr 2010 at 3:14

[GoogleCodeExporter]

As of release 0.9.2, Socket Sentry is caching the results of user database 
lookups
itself. Even if it does not get a response from libc, it will not request a 
lookup
for the same UID again until its own cache entry expires some time later. I 
think
that solves the problem even if libc/nscd misbehaves.

Original comment by rhasselb...@gmail.com on 7 Apr 2010 at 3:39