Feature changed by: Ruediger Meier (rudi_m) Feature #312272, revision 11 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to /bin openSUSE Distribution: Done 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. -- openSUSE Feature: https://features.opensuse.org/312272