Hi,
I wrote a utility that checks all apps in /bin & /sbin to see if they link against anything in /usr. Is this a problem that we care about?
/bin/rpm uses something in /usr /sbin/arping uses something in /usr /sbin/audispd-zos-remote uses something in /usr /sbin/audisp-prelude uses something in /usr /sbin/audisp-remote uses something in /usr /sbin/auditd uses something in /usr /sbin/cifs.upcall uses something in /usr /sbin/grubby uses something in /usr /sbin/lsusb uses something in /usr /sbin/nash uses something in /usr /sbin/setkey uses something in /usr /sbin/umount.hal uses something in /usr
This was not an everything install.
-Steve
Hi,
I wrote a utility that checks all apps in /bin & /sbin to see if they link against anything in /usr. Is this a problem that we care about?
/bin/rpm uses something in /usr /sbin/arping uses something in /usr /sbin/audispd-zos-remote uses something in /usr /sbin/audisp-prelude uses something in /usr /sbin/audisp-remote uses something in /usr /sbin/auditd uses something in /usr /sbin/cifs.upcall uses something in /usr /sbin/grubby uses something in /usr /sbin/lsusb uses something in /usr /sbin/nash uses something in /usr /sbin/setkey uses something in /usr /sbin/umount.hal uses something in /usr
This was not an everything install.
I would think that we would care. I'd be very curious to see the results of this run on an everything install. And the code. :)
-Steve
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thursday 25 September 2008 13:32:00 Jon Ciesla wrote:
This was not an everything install.
I would think that we would care. I'd be very curious to see the results of this run on an everything install. And the code. :)
This and about 10-15 other programs are part of a collection of programs I run as a post install check.
From ~/.rpmmacros:
%__arch_install_post ~/checks/rpm-checks \ /usr/lib/rpm/check-rpaths \ /usr/lib/rpm/check-buildroot
this is the new program. Its designed to take a directory path so it can be pointed to the rpm build install dir. It otherwise defaults to "/" for everything install testing.
-Steve
#!/bin/sh if [ $# -ge 2 ] ; then echo "Usage: check-root-usr [directory]" 1>&2 exit 1 fi DIR="/" if [ $# -eq 1 ] ; then if [ -d "$1" ] ; then DIR="$1" else echo "Option passed in was not a directory" 1>&2 exit 1 fi fi
rc=0 ROOT="/bin /sbin" for d in $ROOT do # Skip dirs that are not in the package if [ ! -e $DIR/$d ] ; then continue fi files=`ls $DIR/$d` for f in $files do # Skip apps we can't read if [ ! -r $DIR$d/$f ] ; then continue fi # Skip static linked apps ldd $DIR$d/$f 2>/dev/null 1>&2 if [ $? -eq 1 ] ; then continue fi ldd $DIR$d/$f | grep '/usr/' 2>/dev/null 1>&2 if [ $? -eq 0 ] ; then echo "$d/$f uses something in /usr:" ldd $DIR$d/$f | grep '/usr/' 2>/dev/null rc=1 fi done done exit $rc
On 2008-09-25 12:32:00 PM, Jon Ciesla wrote:
I would think that we would care. I'd be very curious to see the results of this run on an everything install. And the code. :)
Here's my command and the output: for file in /bin/* /sbin/*; do ldd $file 2>/dev/null | grep /usr > /dev/null 2>&1 && echo $file; done
/bin/rpm /sbin/arping /sbin/cifs.upcall /sbin/grubby /sbin/lsusb /sbin/mkfs.ntfs /sbin/multipath /sbin/multipathd /sbin/nash /sbin/rpcbind /sbin/umount.hal /sbin/ypbind
Note that I did not run as root, so this would not include files that are only root-readable.
Thanks, Ricky
Steve Grubb (sgrubb@redhat.com) said:
I wrote a utility that checks all apps in /bin & /sbin to see if they link against anything in /usr. Is this a problem that we care about?
For things that actually need run when /usr may not be available (grrr), it's needed. In the ones you list below, that would include arping, and audit*. For things like rpm or initrd-related tools, it's not really an issue. (Of course, they may not actaully need to be in /sbin, but it may be more trouble to move them.)
Bill
On Thursday 25 September 2008 13:41:42 Bill Nottingham wrote:
Steve Grubb (sgrubb@redhat.com) said:
I wrote a utility that checks all apps in /bin & /sbin to see if they link against anything in /usr. Is this a problem that we care about?
For things that actually need run when /usr may not be available (grrr), it's needed. In the ones you list below, that would include arping, and audit*.
So, that brings up an interesting point...rsyslog has a gssapi plugin. It starts about the same time as auditd. If the plugin is installed and enabled...wouldn't rsyslog have the same problem as auditd? (Both are wanting the gssapi library.)
-Steve
On Thu, 2008-09-25 at 13:28 -0400, Steve Grubb wrote:
Hi,
I wrote a utility that checks all apps in /bin & /sbin to see if they link against anything in /usr. Is this a problem that we care about?
/bin/rpm uses something in /usr /sbin/arping uses something in /usr /sbin/audispd-zos-remote uses something in /usr /sbin/audisp-prelude uses something in /usr /sbin/audisp-remote uses something in /usr /sbin/auditd uses something in /usr /sbin/cifs.upcall uses something in /usr /sbin/grubby uses something in /usr /sbin/lsusb uses something in /usr /sbin/nash uses something in /usr /sbin/setkey uses something in /usr /sbin/umount.hal uses something in /usr
On which Fedora version did you run this, Steve? The /sbin/setkey should be fixed in rawhide in regards to this problem.
On Thursday 25 September 2008 14:32:35 Tomas Mraz wrote:
On which Fedora version did you run this, Steve?
Good point. It was F-9 for the record. Rawhide shows this:
/bin/mail uses something in /usr: /bin/mailx uses something in /usr: /bin/rpm uses something in /usr: /sbin/audispd-zos-remote uses something in /usr: /sbin/audisp-prelude uses something in /usr: /sbin/audisp-remote uses something in /usr: /sbin/auditd uses something in /usr: /sbin/cifs.spnego uses something in /usr: /sbin/dhcp6c uses something in /usr: /sbin/grubby uses something in /usr: /sbin/lspci uses something in /usr: /sbin/nash uses something in /usr: /sbin/netlabelctl uses something in /usr: /sbin/rpcbind uses something in /usr: /sbin/setpci uses something in /usr: /sbin/umount.hal uses something in /usr: /sbin/ypbind uses something in /usr:
-Steve
Steve Grubb wrote:
Hi,
I wrote a utility that checks all apps in /bin & /sbin to see if they link against anything in /usr. Is this a problem that we care about?
/bin/rpm uses something in /usr /sbin/arping uses something in /usr /sbin/audispd-zos-remote uses something in /usr /sbin/audisp-prelude uses something in /usr /sbin/audisp-remote uses something in /usr
I don't see why the above need to be in /bin or /sbin.
/sbin/auditd uses something in /usr
This is a problem. The sorts of people who care about auditd may want to rely on having a separate /usr partition to minimize the amount of code on their system that could possibly run before auditd is up and running.
/sbin/cifs.upcall uses something in /usr
I don't think a lot of people are mounting /usr over cifs, but on principle, I don't think we should have filesystem-related things depending on /usr.
/sbin/grubby uses something in /usr
I would think we really only need to be calling grubby when the system is fully booted.
/sbin/lsusb uses something in /usr
This could be a problem for people booting off USB devices. Mostly this is only used for liveCD/liveUSB, so we don't hit it, but with the rise of netbooks and such where people may want to boot off a USB-attached SD card, it could come up. I don't think it's a high priority, but if there's an easy fix, we should do it.
/sbin/nash uses something in /usr
That sounds bad.
/sbin/setkey uses something in /usr /sbin/umount.hal uses something in /usr
Is HAL supposed to be involved with system partitions? I was under the impression that it is not, so this doesn't need to be in /sbin.
-- Chris
On Thu, 2008-09-25 at 21:02 -0400, Chris Snook wrote:
Steve Grubb wrote:
/sbin/lsusb uses something in /usr
This could be a problem for people booting off USB devices. Mostly this is only used for liveCD/liveUSB, so we don't hit it, but with the rise of netbooks and such where people may want to boot off a USB-attached SD card, it could come up. I don't think it's a high priority, but if there's an easy fix, we should do it.
Nothing involved in booting off of USB requires lsusb. It's purely a diagnostic tool. And you can get all of the information also via /proc or /sys
/sbin/umount.hal uses something in /usr
Is HAL supposed to be involved with system partitions? I was under the impression that it is not, so this doesn't need to be in /sbin.
It has to be in /sbin because mount helpers are only looked for in /sbin
Jeremy
On Friday 26 September 2008 02:02:44 Chris Snook wrote:
Steve Grubb wrote:
...
/bin/rpm uses something in /usr
...
I don't see why the above need to be in /bin or /sbin.
It can help in (admittedly quite odd situations) where you need to, say, reinstall grub or a kernel because you broke something ;o) Also, admittedly, in that case, I was able to mount /usr before proceeding, but if the package I'd needed to reinstall was providing "mount" and that was broken ... meh. I know we have rescue disks, but there are still machines without working optical drives. Honestly, there are. Now, adding a "rescue" initrd would halfway help here ... think that thread died now though.
On Fri, Sep 26, 2008 at 3:55 AM, Bill Crawford billcrawford1970@gmail.com wrote:
On Friday 26 September 2008 02:02:44 Chris Snook wrote:
Steve Grubb wrote:
...
/bin/rpm uses something in /usr
...
I don't see why the above need to be in /bin or /sbin.
It can help in (admittedly quite odd situations) where you need to, say, reinstall grub or a kernel because you broke something ;o) Also, admittedly, in that case, I was able to mount /usr before proceeding
On the rpm5 list, Jeff Johnson mentioned that /bin/rpm was just a legacy thing that people expected and has since changed the package to install to $bindir (/usr/bin). Not that that applies here exactly, but making /bin/rpm usable when /usr is not available would require moving a lot of things to /lib.
-- Dan
On Friday 26 September 2008 14:43:11 Dan Nicholson wrote:
On the rpm5 list, Jeff Johnson mentioned that /bin/rpm was just a legacy thing that people expected and has since changed the package to install to $bindir (/usr/bin). Not that that applies here exactly, but making /bin/rpm usable when /usr is not available would require moving a lot of things to /lib.
Not that big a list, but hardly worth it.
Long term, I'll admit that getting rid of separate /usr may be a good idea, Solaris appears to have done away with it a while ago (which surprised me, since they used to make explicit provision for having shared /usr in their package management system).
Anyway, there are quite a few situations in which you're basically screwed unless you can run your package manager (and possibly things like ldconfig) so I'd like to add another vote in favour of adding a "create a rescue image" command somewhere ...
Once upon a time, Bill Crawford billcrawford1970@gmail.com said:
Long term, I'll admit that getting rid of separate /usr may be a good idea, Solaris appears to have done away with it a while ago (which surprised me, since they used to make explicit provision for having shared /usr in their package management system).
I use a separate (but not shared) /usr on my servers, and I mount it read-only. My reasoning is that / has to be read-write still for some things (root's home directory, /etc/passwd and /etc/shadow, etc.). I keep a small / that is read-write, but having a good chunk of the installed stuff in /usr mounted read-only makes it a little "safer" (i.e. an attacker would have to remount it to modify it, filesystem corruption is unlikely on a read-only FS, etc.).
On Fri, Sep 26, 2008 at 11:34 AM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Bill Crawford billcrawford1970@gmail.com said:
Long term, I'll admit that getting rid of separate /usr may be a good idea, Solaris appears to have done away with it a while ago (which surprised me, since they used to make explicit provision for having shared /usr in their package management system).
I use a separate (but not shared) /usr on my servers, and I mount it read-only.
I suggest using SELinux (if you're not already) instead; it provides far stronger security than messing with the filesystem layout ever can.
On Friday 26 September 2008 12:00:18 Colin Walters wrote:
I use a separate (but not shared) /usr on my servers, and I mount it read-only.
I suggest using SELinux (if you're not already) instead; it provides far stronger security than messing with the filesystem layout ever can.
Security should be in layers. But aside from security, this is typically used to prevent accidental overwrites of important files.
-Steve
Once upon a time, Colin Walters walters@verbum.org said:
On Fri, Sep 26, 2008 at 11:34 AM, Chris Adams cmadams@hiwaay.net wrote:
I use a separate (but not shared) /usr on my servers, and I mount it read-only.
I suggest using SELinux (if you're not already) instead; it provides far stronger security than messing with the filesystem layout ever can.
Since you snipped my reasons, can you explain how SELinux protects against accidental filesystem corruption?
On Fri, Sep 26, 2008 at 10:34:35AM -0500, Chris Adams wrote:
Once upon a time, Bill Crawford billcrawford1970@gmail.com said:
Long term, I'll admit that getting rid of separate /usr may be a good idea, Solaris appears to have done away with it a while ago (which surprised me, since they used to make explicit provision for having shared /usr in their package management system).
I use a separate (but not shared) /usr on my servers, and I mount it read-only. My reasoning is that / has to be read-write still for some things (root's home directory, /etc/passwd and /etc/shadow, etc.). I keep a small / that is read-write, but having a good chunk of the installed stuff in /usr mounted read-only makes it a little "safer" (i.e. an attacker would have to remount it to modify it, filesystem corruption is unlikely on a read-only FS, etc.).
I'll mention in passing that OLPC is both extremely interested in (and well on its way) to shipping something rather like a read-only / as part of our security and update schemes. (The weasel words are due the fact that, in our design, we chroot through a symlink tree at boot in order to permit easy atomic OS updates and use both file-mounted tmpfsen and a custom NSS module to deal with the small number of writes that still must be permitted.) Anyway, suffice it to say that I'd enjoy hearing more about your progress toward a read-only / as you make it.
Regards,
Michael
Chris Snook wrote:
/sbin/nash uses something in /usr
That sounds bad.
Why? When it's running during boot, it's on its own filesystem in ram anyway.
On Wed, 2008-10-01 at 11:54 -0400, Peter Jones wrote:
Chris Snook wrote:
/sbin/nash uses something in /usr
That sounds bad.
Why? When it's running during boot, it's on its own filesystem in ram anyway.
Given its very limited use, one could argue that the nash binary doesn't belong into any *bin directory, but e.g. /usr/libexec or even /usr/lib[64]. Or does somebody use it in a running system outside of the initrd?
Nils
On Thu, 2008-10-02 at 12:46 +0200, Nils Philippsen wrote:
Given its very limited use, one could argue that the nash binary doesn't belong into any *bin directory, but e.g. /usr/libexec or even /usr/lib[64]. Or does somebody use it in a running system outside of the initrd?
In the past, it was used by rc.sysinit for a few things but hasn't been for quite a while. So yes, it probably could be moved at this point
Jeremy