According to "man 7 hier" /sbin is a better place for kmod binaries and tools. Reproducible: Always
Created attachment 332572 [details, diff] Patch for kmod-12 and kmod-9999
Created attachment 332576 [details, diff] Patch for kmod-12 and kmod-9999 (with EPREFIX)
I'm quite sure to know how this bug ends but let's see and hope for the better :-/
The binaries are installed exactly where module-init-tools used to put them for compability reasons. I don't know if it makes any sense to break that, some of the binaries like lsmod work fine as normal user.
(In reply to comment #4) > The binaries are installed exactly where module-init-tools used to put them > for compability reasons. I don't know if it makes any sense to break that, > some of the binaries like lsmod work fine as normal user. This is not about lsmod working fine if called by a normal user. A normal user has nothing to do with modules management. Even if he can view loaded modules list, he has no use of it, he can't modify it, can't load/remove modules, etc. Same is with ifconfig and some other tools. There is a strong distinction between system configuration tools like kmod and general tools like cp or ls. The former should go to /sbin, as hier(7) states, the later is to be in /bin.
btw, there are other tools located in /bin that are to be in /sbin. ~> login login: Cannot possibly work without effective root ~> which login /bin/login as an example. I suppose this should be fixed.
(In reply to comment #5) > (In reply to comment #4) > > The binaries are installed exactly where module-init-tools used to put them > > for compability reasons. I don't know if it makes any sense to break that, > > some of the binaries like lsmod work fine as normal user. > > This is not about lsmod working fine if called by a normal user. A normal > user has nothing to do with modules management. Even if he can view loaded > modules list, he has no use of it, he can't modify it, can't load/remove > modules, etc. Same is with ifconfig and some other tools. There is a strong > distinction between system configuration tools like kmod and general tools > like cp or ls. The former should go to /sbin, as hier(7) states, the later > is to be in /bin. ifconfig, ip, kmod, etc can be seen as having system functions and allowing users to view settings. It is up to the software itself to make sure that users do not have access to the functions they cannot perform, not the location of the software. Also, keep in mind that Gentoo has never claimed to follow the FHS to the letter.
The udev team all agree that this isn't a bug. It is fine for kmod to be in /bin.
(In reply to comment #4) > The binaries are installed exactly where module-init-tools used to put them > for compability reasons. I don't know if it makes any sense to break that, > some of the binaries like lsmod work fine as normal user. This is incorrect. Here are the locations that module-init-tools uses: $ find /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/ /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/ /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/sbin /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/sbin/depmod /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/sbin/modinfo /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/sbin/rmmod /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/sbin/modprobe /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/sbin/update-modules /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/sbin/insmod /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/etc /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/etc/modprobe.d /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/etc/modprobe.d/usb-load-ehci-first.conf /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/doc /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/doc/module-init-tools-3.16-r2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/doc/module-init-tools-3.16-r2/ChangeLog.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/doc/module-init-tools-3.16-r2/AUTHORS.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/doc/module-init-tools-3.16-r2/README.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/doc/module-init-tools-3.16-r2/TODO.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/doc/module-init-tools-3.16-r2/NEWS.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man8 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man8/modinfo.8.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man8/lsmod.8.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man8/modprobe.8.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man8/rmmod.8.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man8/depmod.8.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man8/insmod.8.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man8/update-modules.8.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man5 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man5/modules.dep.bin.5.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man5/modprobe.conf.5.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man5/modprobe.d.5.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man5/depmod.conf.5.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man5/modules.dep.5.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/usr/share/man/man5/depmod.d.5.bz2 /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/bin /var/tmp/portage/sys-apps/module-init-tools-3.16-r2/image/bin/lsmod Here are the locations that kmod uses: $ find /var/tmp/portage/sys-apps/kmod-9999/image/ /var/tmp/portage/sys-apps/kmod-9999/image/ /var/tmp/portage/sys-apps/kmod-9999/image/sbin /var/tmp/portage/sys-apps/kmod-9999/image/sbin/modprobe /var/tmp/portage/sys-apps/kmod-9999/image/sbin/depmod /var/tmp/portage/sys-apps/kmod-9999/image/lib64 /var/tmp/portage/sys-apps/kmod-9999/image/lib64/libkmod.so.2 /var/tmp/portage/sys-apps/kmod-9999/image/lib64/libkmod.so.2.2.2 /var/tmp/portage/sys-apps/kmod-9999/image/usr /var/tmp/portage/sys-apps/kmod-9999/image/usr/include /var/tmp/portage/sys-apps/kmod-9999/image/usr/include/libkmod.h /var/tmp/portage/sys-apps/kmod-9999/image/usr/share /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/doc /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/doc/kmod-9999 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/doc/kmod-9999/TODO.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/doc/kmod-9999/NEWS.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/doc/kmod-9999/README.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man8 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man8/rmmod.8.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man8/lsmod.8.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man8/depmod.8.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man8/insmod.8.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man8/modinfo.8.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man8/modprobe.8.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man5 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man5/modprobe.d.5.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man5/modules.dep.bin.5.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man5/depmod.d.5.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/share/man/man5/modules.dep.5.bz2 /var/tmp/portage/sys-apps/kmod-9999/image/usr/lib64 /var/tmp/portage/sys-apps/kmod-9999/image/usr/lib64/libkmod.so /var/tmp/portage/sys-apps/kmod-9999/image/usr/lib64/pkgconfig /var/tmp/portage/sys-apps/kmod-9999/image/usr/lib64/pkgconfig/libkmod.pc /var/tmp/portage/sys-apps/kmod-9999/image/bin /var/tmp/portage/sys-apps/kmod-9999/image/bin/insmod /var/tmp/portage/sys-apps/kmod-9999/image/bin/modinfo /var/tmp/portage/sys-apps/kmod-9999/image/bin/lsmod /var/tmp/portage/sys-apps/kmod-9999/image/bin/depmod /var/tmp/portage/sys-apps/kmod-9999/image/bin/modprobe /var/tmp/portage/sys-apps/kmod-9999/image/bin/kmod /var/tmp/portage/sys-apps/kmod-9999/image/bin/rmmod /var/tmp/portage/sys-apps/kmod-9999/image/lib /var/tmp/portage/sys-apps/kmod-9999/image/lib/modprobe.d /var/tmp/portage/sys-apps/kmod-9999/image/lib/modprobe.d/usb-load-ehci-first.conf insmod, rmmod and others have been moved from /sbin in module-init-tools to /bin in kmod. If we are trying to install binaries where module-init-tools used to put them for compatibility, then this would constitute a regression. This bug was closed as invalid on the basis that module-init-tools used /bin, which is incorrect. As such, I am taking the liberty to reopen this bug for an alternative resolution.
(In reply to comment #9) > This bug was closed as invalid on the basis that module-init-tools used > /bin, which is incorrect. As such, I am taking the liberty to reopen this > bug for an alternative resolution. You're my favorite gentoo developer ^___^
fhs is meaningless, but, right, scratch my last comment, looking at this with fresh eyes now: revisiting the paths from notes: - Linux source tree is hardcoding /sbin/{depmod,modprobe} paths, so +1 for using /sbin for long as they are doing that - lsmod needs to stay in /bin to be in default $PATH for everyone, and that it does now the logic behind dumping rest to /bin was simply that distributions like Fedora where udev is currently living in the systemd tree is actually dropping the consept of sbin from their $PATH entirely fixed in kmod-12-r1 and 9999
left kmod binary in /bin as per upstream, and because it's a "new binary" when moving from m-i-t to kmod, and this ChangeLog entry: *kmod-11-r4 (04 Dec 2012) 04 Dec 2012; William Hubbs <williamh@gentoo.org> +kmod-11-r4.ebuild, kmod-9999.ebuild: Upstream recommended to me that we install the kmod binary in /bin.
(In reply to comment #11) > the logic behind dumping rest to /bin was simply that distributions like > Fedora where udev is currently living in the systemd tree is actually > dropping the consept of sbin from their $PATH entirely Like I already told several times we're NOT stupid fedora monkeys who do every crap they are imposing on their users. It's about time to stop this nonsense. We're grown ups who can meet our own decisions and dumping sbin is idiotic.
(In reply to comment #12) > left kmod binary in /bin as per upstream, and because it's a "new binary" > when moving from m-i-t to kmod, and this ChangeLog entry: > > *kmod-11-r4 (04 Dec 2012) > > 04 Dec 2012; William Hubbs <williamh@gentoo.org> +kmod-11-r4.ebuild, > kmod-9999.ebuild: > Upstream recommended to me that we install the kmod binary in /bin. I hope somebody listens to Lars here, because I seems lack enough 'status' for everyone to listen to me.
(In reply to comment #11) > fhs is meaningless, but, right, scratch my last comment, looking at this > with fresh eyes now: > > revisiting the paths from notes: > > - Linux source tree is hardcoding /sbin/{depmod,modprobe} paths, so +1 for > using /sbin for long as they are doing that > - lsmod needs to stay in /bin to be in default $PATH for everyone, and that > it does now > > the logic behind dumping rest to /bin was simply that distributions like > Fedora where udev is currently living in the systemd tree is actually > dropping the consept of sbin from their $PATH entirely That's not how I was thinking per se. I was just thinking that the difference between sbin and bin doesn't really matter as much these days, and it is up to the software to make sure it is run with the correct priveleges. Security by obscurity (hiding sbin from the path) does not work. We have had kmod in ~arch for some time, and we haven't received any bugs wrt packages hard coding the other paths to /sbin the way the kernel tree hard codes depmod and modprobe.
@qa: I am re-opening and escalating this bug to you for a second opinion. Comment #9 shows that we were installing some of the symbolic links which module-init-tools put in /sbin in /bin. We wanted to move all of them originally, but we found that the kernel build process hard codes paths for modprobe and depmod to /sbin. We do not know of any other packages that hard code paths to the module-init-tools binaries, and if there are packages that do this, I don't know of any way to find them besides moving the links to /bin. So, what is your opinion? Should we move the links to /bin instead of /sbin and possibly add an ewarn to the ebuild?
(In reply to comment #14) > (In reply to comment #12) > > left kmod binary in /bin as per upstream, and because it's a "new binary" > > when moving from m-i-t to kmod, and this ChangeLog entry: > > > > *kmod-11-r4 (04 Dec 2012) > > > > 04 Dec 2012; William Hubbs <williamh@gentoo.org> +kmod-11-r4.ebuild, > > kmod-9999.ebuild: > > Upstream recommended to me that we install the kmod binary in /bin. > > I hope somebody listens to Lars here, because I seems lack enough 'status' > for everyone to listen to me. It is not a matter of status. It is a matter of people not being on the same page as far as priorities go. Anyway, I agree with Lars here. kmod is only useful to root, so it should go into sbin. That is where binaries belonging to the superuser are meant to go.
kmod as a new binary can go to bin., otherwise sbin seems like the compromise here, and nobody should really have issues with keeping the files where they are in module-init-tools, covers every possible compability problem with them. sorry but this bug is done.
(In reply to comment #18) > kmod as a new binary can go to bin., otherwise sbin seems like the > compromise here, and nobody should really have issues with keeping the files > where they are in module-init-tools, covers every possible compability > problem with them. > sorry but this bug is done. I have to withdraw my earlier statements that kmod should go into /sbin. We put ifconfig into /bin because it supported listing interfaces to users. kmod supports listing modules and lsmod has been in /bin for a while. To be consistent, we should have kmod in /bin. With that said, the recent changes to our kmod package moved lsmod to /sbin. It should be changed to put lsmod in /bin. This is consistent with our previous discussions in IRC about not changing paths.
As Samuli and Richard say, stuff like lsmod can be useful for users and having them in the path can help, /bin is good to me for them.
Following this line of thinking, modinfo can go to /bin, agreed?
(In reply to comment #21) > Following this line of thinking, modinfo can go to /bin, agreed? I am inclined to say to leave modinfo where it is. It has been there long enough that moving it will likely cause regressions. Most of us want to avoid regressions.
(In reply to comment #22) > (In reply to comment #21) > > Following this line of thinking, modinfo can go to /bin, agreed? > > I am inclined to say to leave modinfo where it is. It has been there long > enough that moving it will likely cause regressions. Most of us want to > avoid regressions. As an additional note, I do not see the use of modinfo to regular users. Users are not going to load modules, so they do not need to know about module parameters. That is my opinion. Diego might have a different opinion.
Can't you just install kmod into /bin and create symlinks into /sbin for compatibility reasons? (Just an idea.)
(In reply to comment #24) > Can't you just install kmod into /bin and create symlinks into /sbin for > compatibility reasons? (Just an idea.) Most of these "binaries" are symlinks to kmod. It is what is known as a multicall binary. Anyway, the symlinks are meant to be placed in locations that module-init-tools used for compatibility purposes. Anyway, I don't think many people still want the kmod binary to go into /sbin. My explanation in comment #19 likely changed people's minds. With that said, the only thing left to do here is move lsmod back to /bin, assuming that someone didn't move it already without posting that here.
Actually, I made a mistake. ssuominen never moved lsmod to /sbin. I am going to close this as resolved. It is time to put this discussion to rest.
