[New: openFATE 312272] Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to %_bindir
Feature added by: Johannes Obermayr (jobermayr) Feature #312272, revision 1 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to %_bindir openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: 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, ...) -- openSUSE Feature: https://features.opensuse.org/312272
Feature changed by: Johannes Obermayr (jobermayr) Feature #312272, revision 2 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to %_bindir openSUSE Distribution: Unconfirmed 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, ...) -- openSUSE Feature: https://features.opensuse.org/312272
Feature changed by: Sascha Peilicke (saschpe) Feature #312272, revision 3 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to %_bindir openSUSE Distribution: Unconfirmed 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. -- openSUSE Feature: https://features.opensuse.org/312272
Feature changed by: Sascha Peilicke (saschpe) Feature #312272, revision 4 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to %_bindir openSUSE Distribution: Unconfirmed Priority Requester: Mandatory + Info Provider: (Novell) 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. -- openSUSE Feature: https://features.opensuse.org/312272
Feature changed by: Dr. Werner Fink (WernerFink) Feature #312272, revision 5 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to %_bindir - openSUSE Distribution: Unconfirmed + openSUSE Distribution: Rejected by Dr. Werner Fink (wernerfink) + reject date: 2011-04-27 10:11:39 + reject reason: Invalid request Priority Requester: Mandatory - Info Provider: (Novell) 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. + #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 -- openSUSE Feature: https://features.opensuse.org/312272
Feature changed by: Michal Marek (michal-m) Feature #312272, revision 6 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to - %_bindir + /bin - openSUSE Distribution: Rejected by Dr. Werner Fink (wernerfink) - reject date: 2011-04-27 10:11:39 - reject reason: Invalid request + 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. #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. -- openSUSE Feature: https://features.opensuse.org/312272
Feature changed by: Johannes Obermayr (jobermayr) Feature #312272, revision 8 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. -- openSUSE Feature: https://features.opensuse.org/312272
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
Feature changed by: Sascha Peilicke (saschpe) Feature #312272, revision 10 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to /bin - openSUSE Distribution: New + 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. -- openSUSE Feature: https://features.opensuse.org/312272
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
Feature changed by: Johannes Obermayr (jobermayr) Feature #312272, revision 12 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. + #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! -- openSUSE Feature: https://features.opensuse.org/312272
Feature changed by: Johannes Obermayr (jobermayr) Feature #312272, revision 13 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to /bin - openSUSE Distribution: Done + 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! -- openSUSE Feature: https://features.opensuse.org/312272
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
Feature changed by: Ruediger Meier (rudi_m) Feature #312272, revision 15 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! + #12: Ruediger Meier (rudi_m) (2011-05-06 17:59:44) (reply to #10) + > [...] if a normal (not a system administrator) user will ever run it + directly [..] + "not _A_ system administrator" - they mean a system users which is not + able to su root. Why should one try to debug the initrd if he is not + able to su root? Should we move all binaries where others have the x + bit to /bin? what about sysctl -a modinfo xyz and many other useful + tools the advanced user needs every day ... Are they all at the wrong + place? + > http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/sbin.html + (http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/sbin.html) + Did you've read the first line? "Linux discriminates between 'normal' + executables and those used for system maintenance and/or administrative + tasks. ..." + If you are fooling around with lsinitrd then you are clearly in + maintanace/administrative/curiosity mode. This is independent of which + system user you are or which default PATH is set for the users. #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
[...] if a normal (not a system administrator) user will ever run it
http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/sbin.html (http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/sbin.html) Did you've read the first line? "Linux discriminates between 'normal' executables and those used for system maintenance and/or administrative tasks. ..." If you are fooling around with lsinitrd then you are clearly in
Feature changed by: Tomáš Chvátal (scarabeus_iv) Feature #312272, revision 17 Title: Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to /bin - openSUSE Distribution: New + openSUSE Distribution: Rejected by Tomáš Chvátal (scarabeus_iv) + reject reason: We moved those we wanted. Rest won't be done or + alternatively focused per item basis via bugs. 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! #12: Ruediger Meier (rudi_m) (2011-05-06 17:59:44) (reply to #10) directly [..] "not _A_ system administrator" - they mean a system users which is not able to su root. Why should one try to debug the initrd if he is not able to su root? Should we move all binaries where others have the x bit to /bin? what about sysctl -a modinfo xyz and many other useful tools the advanced user needs every day ... Are they all at the wrong place? maintanace/administrative/curiosity mode. This is independent of which system user you are or which default PATH is set for the users. #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
participants (1)
-
fate_noreply＠suse.de