Home_greyopenFATE - openSUSE feature tracking > #312272
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Move /sbin/lsinitrd, /sbin/lsmod, /sbin/lspci, /sbin/lspcmcia to /bin

Feature state

openSUSE Distribution
Rejected Information


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 ...

User benefit:

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, ...)


icons/user_comment.png S. P. wrote: (7 years ago)

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.

icons/user_comment.png J. O. wrote: (7 years ago)

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 ...

icons/user_comment.png S. P. wrote: (7 years ago)

This is just childish and surely not part of convincing anyone, no?

icons/user_comment.png D. W. wrote: (7 years ago)

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


to their ~/.profile

icons/user_comment.png M. M. wrote: (7 years ago)

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.

icons/user_comment.png R. M. wrote: (7 years ago)

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.


$ 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.

icons/user_comment.png S. P. wrote: (7 years ago)

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).

icons/user_comment.png S. P. wrote: (7 years ago)

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 assuming that this isn't the case.

icons/user_comment.png R. M. wrote: (7 years ago)

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.

icons/user_comment.png J. O. wrote: (7 years ago)

"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!

icons/user_comment.png R. M. wrote: (7 years ago)

> [...] 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?


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.

icons/user_comment.png J. O. wrote: (7 years ago)

You must not close a feature that is only partly done.

Reopened ...

Last change: 11 months ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint