Feature changed by: Johannes Obermayr (jobermayr) Feature #312272, revision 14 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 ... #8: Sascha Peilicke (saschpe) (2011-05-05 10:27:28) (reply to #4) This is just childish and surely not part of convincing anyone, no? #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. #7: Sascha Peilicke (saschpe) (2011-05-05 10:24:27) (reply to #3) Once again, you don't need to be root to access /sbin binaries. You just have to either add /sbin to your $PATH or invoke it with it's absolute path (i.e. /sbin/lsinitrd). #6: Sascha Peilicke (saschpe) (2011-05-05 10:27:53) To make this clear once more, I'm not against moving stuff around, just the rationale makes little sense. You should be aware that you don't need root privileges to access /sbin. Also, have you checked that /sbin/lsinitrd isn't used in other boot- time scripts? I'm going to accept sr # 69616 (https://build.opensuse.org/request/show/69616) assuming that this isn't the case. #9: Ruediger Meier (rudi_m) (2011-05-06 16:33:58) (reply to #6) IMO it's very pitty that you've accepted it. The fact that it's not really important whether lsinitrd lives in /bin or /sbin makes it look even more stupid to move it around for fun than the fact that /sbin is the better place. lsinitrd is a very simple special script with no much functionality which is usually used by advanced users or admins only. These users should be able to find it in /sbin and if they found it there in past then they will miss it there now. #10: Johannes Obermayr (jobermayr) (2011-05-06 17:21:48) (reply to #6) "Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path." (see: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/sbin.html) I hope it is clear now! + #11: Johannes Obermayr (jobermayr) (2011-05-06 17:31:30) + You must not close a feature that is only partly done. + Reopened ... -- openSUSE Feature: https://features.opensuse.org/312272