Feature changed by: Ruediger Meier (rudi_m) Feature #312272, revision 9 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to /bin openSUSE Distribution: New Priority Requester: Mandatory Requested by: Johannes Obermayr (jobermayr) Developer: Johannes Obermayr (jobermayr) Partner organization: openSUSE.org Description: lsinitrd, lsmod, lspci, lspcmcia are located in /sbin and so only root can access them. The 'ls' prefix indicates that these programs only list some information which should be accessible by all users. lsusb is in %_bindir (=/usr/bin). If you were consequently lsusb also would have to be in /sbin or /usr/sbin ... Business case (Partner benefit): openSUSE.org: There absolutely is not any sense for having programs just providing information in /sbin. How do you want to help people if you need for example lspci's output and then people complain: "Absolute path to 'lspci' is '/sbin/lspci', so running it may require superuser privileges (eg. root)." Can you give me root's password? (security, security, security, ...) Discussion: #1: Sascha Peilicke (saschpe) (2011-04-27 09:55:45) Nonsense, the 'ls' prefix indicates nothing. Furthermore, the user can happily invoke anything under /sbin (given propper permissions, which is the case for /sbin/lspci). One minor difference is that /sbin isn't part of a normal user's $PATH by default. Even more so, important tools like lsmod, lspci can't reside under /usr/ as they are required at boot time. However, moving /sbin/lsinitrd to /bin may make sense. #4: Johannes Obermayr (jobermayr) (2011-04-27 14:20:52) (reply to #1) Maybe you should search for meanings: ls = list ls = listing (Unix command) see: http://www.acronymfinder.com/LS.html Or would you say the mk prefix is not the abbreviation for 'make' but 'delete'? 'Easy thinking' is key to success ... #2: Dr. Werner Fink (wernerfink) (2011-04-27 10:10:12) Moving system tools used at boot from /sbin/ to /usr/bin/, that is that /usr/ could be an own partition mounted ro and a network share, is a NOGO. Beside this normal users should not be enforced to use those commands. Interested users may add the line PATH=/sbin:/usr/sbin:$PATH to their ~/.profile #3: Michal Marek (michal-m) (2011-04-27 11:39:19) (reply to #2) Normal users do not use the commandline. And please don't nitpick on the /usr part, the point is to make these commands accessible to non- root, i.e. /bin seems like the logical choice. I updated the subject to make it clear. + #5: Ruediger Meier (rudi_m) (2011-04-27 18:44:25) (reply to #3) + Of course normal users are using commandline at least our users do. But + most of them don't need sysadmin tools in their path the rest just adds + /sbin. + On the other hand it's indeed inconsistent to have lsusb, lsscsi, + lsblk, lsdev in bin/ but lspcmcia and lspci in sbin/. Note that lsmod + is already linked from bin/ (oS 11.4.) and could be removed from the + subject. + See: + $ pin bin/ls | grep "x86_64.rpm\|noarch.rpm" | sed 's/: [^\/]* /\t/g' + | sort + ./suse/noarch/lsb-release-2.0-9.1.noarch.rpm /usr/bin/lsb_release + ./suse/noarch/lsb-release-2.0-9.1.noarch.rpm /usr/bin/lsb-release -> + lsb_release + ./suse/noarch/open-ovf-0.1-8.1.noarch.rpm /usr/bin/lsovf + ./suse/noarch/python-boto-2.0-3.1.noarch.rpm /usr/bin/lss3 + ./suse/x86_64/canna-3.7p3-213.3.x86_64.rpm /usr/bin/lsdic -> + catdic + ./suse/x86_64/coreutils-8.9-4.1.x86_64.rpm /bin/ls + ./suse/x86_64/e2fsprogs-1.41.14-5.1.x86_64.rpm /usr/bin/lsattr + ./suse/x86_64/hal-0.5.14-18.1.x86_64.rpm /usr/bin/lshal + ./suse/x86_64/libcgroup1-0.36.2-5.1.x86_64.rpm /usr/bin/lscgroup + ./suse/x86_64/libcgroup1-0.36.2-5.1.x86_64.rpm /usr/bin/lssubsys + ./suse/x86_64/libmicro-0.4.0-88.1.x86_64.rpm + /usr/lib/libMicro/bin/lseek + ./suse/x86_64/libpst-0.6.49-4.2.x86_64.rpm /usr/bin/lspst + ./suse/x86_64/lskat-4.6.0-3.2.x86_64.rpm /usr/bin/lskat + ./suse/x86_64/lsof-4.84-5.1.x86_64.rpm /usr/bin/lsof + ./suse/x86_64/lsscsi-0.23-6.1.x86_64.rpm /usr/bin/lsscsi + ./suse/x86_64/lsvpd-1.6.5-44.1.x86_64.rpm /sbin/lscfg -> + /usr/sbin/lscfg + ./suse/x86_64/lsvpd-1.6.5-44.1.x86_64.rpm /sbin/lsmcode -> + /usr/sbin/lsmcode + ./suse/x86_64/lsvpd-1.6.5-44.1.x86_64.rpm /sbin/lsvio -> + /usr/sbin/lsvio + ./suse/x86_64/lsvpd-1.6.5-44.1.x86_64.rpm /sbin/lsvpd -> + /usr/sbin/lsvpd + ./suse/x86_64/lsvpd-1.6.5-44.1.x86_64.rpm /usr/sbin/lscfg + ./suse/x86_64/lsvpd-1.6.5-44.1.x86_64.rpm /usr/sbin/lsmcode + ./suse/x86_64/lsvpd-1.6.5-44.1.x86_64.rpm /usr/sbin/lsvio + ./suse/x86_64/lsvpd-1.6.5-44.1.x86_64.rpm /usr/sbin/lsvpd + ./suse/x86_64/lswm-0.6.00-3.1.x86_64.rpm /usr/bin/lswm + ./suse/x86_64/mkinitrd-2.6.0-8.2.x86_64.rpm /sbin/lsinitrd + ./suse/x86_64/module-init-tools-3.12-6.1.x86_64.rpm /bin/lsmod + ./suse/x86_64/module-init-tools-3.12-6.1.x86_64.rpm /sbin/lsmod -> + /bin/lsmod + ./suse/x86_64/nilfs-utils-2.0.14-8.1.x86_64.rpm /usr/bin/lscp + ./suse/x86_64/nilfs-utils-2.0.14-8.1.x86_64.rpm /usr/bin/lssu + ./suse/x86_64/patchutils-0.3.1-10.1.x86_64.rpm /usr/bin/lsdiff -> + filterdiff + ./suse/x86_64/pciutils-3.1.7-8.1.x86_64.rpm /sbin/lspci + ./suse/x86_64/pcmciautils-017-112.1.x86_64.rpm /sbin/lspcmcia -> + pccardctl + ./suse/x86_64/procinfo-18-207.1.x86_64.rpm /usr/bin/lsdev + ./suse/x86_64/syslinux-3.86-7.4.x86_64.rpm /usr/bin/lss16toppm + ./suse/x86_64/usbutils-001-3.1.x86_64.rpm /usr/bin/lsusb + ./suse/x86_64/util-linux-2.19-3.6.1.x86_64.rpm /bin/lsblk + ./suse/x86_64/util-linux-2.19-3.6.1.x86_64.rpm /usr/bin/lscpu + ./suse/x86_64/x86info-1.25-4.1.x86_64.rpm /usr/sbin/lsmsr + ./suse/x86_64/xen-tools-4.0.2_02-4.7.1.x86_64.rpm + /usr/lib64/xen/bin/lsevtchn + So I would probably symlink lspci and lspcmcia from /bin/. I see no + reason to do that for lsinitrd. -- openSUSE Feature: https://features.opensuse.org/312272