selinux policy denials have long id'd kde's konsole app to be leaking file descriptors. It's been an open issue for awhile now, see: https://bugzilla.redhat.com/show_bug.cgi?id=484370 http://bugs.kde.org/show_bug.cgi?id=180785
Unfortunatley, upstream developers, so far, haven't been able to reproduce the problem.
Upon actively digging myself recently, it appears to be something that looks worse than previously identified, going deeper than just konsole. I've ran out of ideas to track this further, any help/insight/pointers appreciated.
-- Rex
Rex Dieter wrote:
selinux policy denials have long id'd kde's konsole app to be leaking file descriptors. ...
Running under valgrind (memcheck) can help, but is costly in time and space. "strace -f -e trace=open,close,dup,dup2" may help, and has reasonable overhead. Setting O_CLOEXEC in every open(), except the ones you "know" need to keep the fd open over execve(), can help you do a binary search. Setting O_CLOEXEC may also mask the underlying logical problem, so beware.
Unfortunatley, upstream developers, so far, haven't been able to reproduce the problem.
Neither https://bugzilla.redhat.com/show_bug.cgi?id=484370 nor http://bugs.kde.org/show_bug.cgi?id=180785 mention anybody who can reproduce it. So document *every* suspected instance.
2009/4/16 Rex Dieter:
selinux policy denials have long id'd kde's konsole app to be leaking file descriptors. It's been an open issue for awhile now, see: https://bugzilla.redhat.com/show_bug.cgi?id=484370 http://bugs.kde.org/show_bug.cgi?id=180785
Unfortunatley, upstream developers, so far, haven't been able to reproduce the problem.
Upon actively digging myself recently, it appears to be something that looks worse than previously identified, going deeper than just konsole. I've ran out of ideas to track this further, any help/insight/pointers appreciated.
I don't know if this is much of an insight ....
If I run "sleep 10000" on a console, using lsof I find the following extra file descriptors open: sleep 12640 paul 4u unix 0xffff88009d543180 0t0 39745 socket sleep 12640 paul 9u unix 0xffff8800b8539e40 0t0 39985 /tmp/ksocket-paul/kdeinit4__0 sleep 12640 paul 10u unix 0xffff88009d543180 0t0 39745 socket sleep 12640 paul 12u unix 0xffff88009d543180 0t0 39745 socket sleep 12640 paul 13u unix 0xffff88009d543180 0t0 39745 socket sleep 12640 paul 14u unix 0xffff88009d543180 0t0 39745 socket
These match up the the AVC denial from SELinux. Further playing with lsof shows that the earliest processes with these open is kdeinit4.
Apologies if I'm teaching you to suck eggs.
-- Paul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rex Dieter wrote:
Upon actively digging myself recently, it appears to be something that looks worse than previously identified, going deeper than just konsole. I've ran out of ideas to track this further, any help/insight/pointers appreciated.
Use
valgrind --track-fds=yes program args...
That'll show you which file descriptors are open at exit time and where they originate. Have the debug info installed for best results.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
John Reiser -
Paul Black -
Rex Dieter -
Ulrich Drepper