linux-kernel - Re: [CFT] Grep to find users of sys

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 20 Oct 2006 08:38:07 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	linux-kernel <linux-kernel@...r.kernel.org>
Cc:	Andrew Morton <akpm@...l.org>, Linus Torvalds <torvalds@...l.org>,
	Albert Cahalan <acahalan@...il.com>,
	Cal Peake <cp@...olutedigital.net>, Andi Kleen <ak@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [CFT] Grep to find users of sys_sysctl.

Jakub Jelinek <jakub@...hat.com> writes:

> This assumes the binaries and/or libraries are not stripped, and they
> usually are stripped.  So, it is better to run something like:
> find / -type f -perm /111 | while read f; do readelf -Ws $f 2>/dev/null | fgrep
> -q sysctl@...BC && echo $f; done

Russell King <rmk+lkml@....linux.org.uk> writes:
> glibc on ARM _requires_ sys_sysctl for userspace ioperm, inb, outb etc
> emulation.


It looks like we have a small but interesting set of sysctl users.

The list of files below is a composite from a number of systems I have
access to, and the reply I have gotten so far.  I'm still hoping to hear
from other people so I can add some other users of sysctl to my list.

I'm still investigating to see how all of these pieces are using
sysctl, and how much they care:
- radvd seems to be an upstanding user.
- libsensors seems to be using sysctls so we have no responsibility to
  maintain the ABI there.
- libpthread uses sysctl but it doesn't much care.
- module_upgrade seems to be setting the printk verbosity?

The nvidia-installer sounds like a scary piece of code.

I'm puzzled why the majority of the users seem to be concentrated
in system configuration software and installers. 

These 


Compiling the results I have so far (Some of these are from older distros):
/sbin/kmodule
/sbin/sndconfig
/usr/X11R6/bin/Xconfigurator
/usr/bin/tiny-nvidia-installer
/usr/bin/nvidia-installer
/usr/sbin/glidelink
/usr/sbin/kudzu
/usr/sbin/module_upgrade
/usr/sbin/mouseconfig
/usr/sbin/radvd
/usr/sbin/updfstab

/usr/lib/libsensors.so.1.2.1
/usr/lib/libsensors.so.3.1.0
/usr/lib/libsensors.so.3.0.9
/usr/lib64/libsensors.so.2.0.0
/usr/lib64/libsensors.so.3.0.9

/usr/lib/python1.5/site-packages/_kudzumodule.so
/usr/lib/python2.2/site-packages/_kudzumodule.so
/usr/lib/python2.3/site-packages/_kudzumodule.so
/usr/lib64/python2.4/site-packages/_kudzumodule.so

/lib/i686/libpthread-0.10.so
/lib/i686/libpthread.so.0
/lib/i686/nosegneg/libpthread-2.4.so
/lib/libpthread-0.10.so
/lib/libpthread-0.9.so
/lib/libpthread.so.0
/lib/tls/libpthread-2.3.3.so
/lib/tls/libpthread-2.3.5.so
/lib/tls/libpthread-2.3.6.so
/lib/tls/libpthread.so.0
/lib/libpthread-2.4.so
/lib64/libpthread.so.0
/lib64/tls/libpthread.so.0
/lib64/libpthread-2.4.so
/usr/i386-glibc22-linux/lib/libpthread-0.9.so
/usr/i386-glibc22-linux/lib/libpthread.so.0


Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/