Fedora Account System
Red Hat Associate
Red Hat Customer
Hi, This small detail related to the "Unify bin and sbin" change. After Fedora 44 finally made /usr/sbin a symlink to /usr/bin, I noticed an inconsistency: As a regular user: echo $(command -v vim) returns: /usr/bin/vim But as root, the same command returns: /usr/sbin/vim This causes /etc/profile.d/vim.sh to fail to set the alias vi=vim for the root user. Since /usr/sbin is added before /usr/bin for root, command -v resolves to /usr/sbin/vim instead of /usr/bin/vim. We need to modify two places. We need to update /etc/login.defs and set: ENV_SUPATH PATH=/usr/bin:/usr/sbin This puts /usr/bin before /usr/sbin. With usrMove, we also no longer need /bin or /sbin in the path. And in /etc/profile we have: # Path manipulation if [ "$EUID" = "0" ]; then pathmunge /usr/sbin pathmunge /usr/local/sbin else pathmunge /usr/local/sbin after pathmunge /usr/sbin after fi My suggestion would be to remove the conditional entirely and always use: pathmunge /usr/local/sbin after pathmunge /usr/sbin after This would make path resolution consistent between regular users and root after the /usr/bin and /usr/sbin unification. This is a suggestion. If you believe the issue lies in the script that uses command -v, or if you have another suggestion for addressing this detail, it would be welcome and I will be happy to review it. Reproducible: Always
Actually, the munging of /usr/sbin can be dropped. /usr/sbin will always be a symlink to /usr/bin, so we don't need to add it. /usr/local/sbin _may_ be separate on upgraded machines, so it's possible that it'll be separate, if the admin installed files there and it cannot be merged automatically. On new installations and 99% of upgraded installations it'll be a symlink too. So… either one of both munges can be dropped. I'd drop both, to simplify the system. Systemd sets $PATH properly, so this munging is unnecessary for local logins. It only can have an effect on remote logins. So if both munges are dropped, the only concern is with compat with remote logins, on upgraded systems where local files were installed in /usr/local/sbin. But this setting of $PATH is not reliable anyway: it only occurs when the user does a shell login, otherwise the default compiled into sshd is used, which on Fedora builds does _not_ include /usr/local/sbin. So the user may do 'ssh host' and get the munged $PATH, but then the can do 'ssh host binary', where the binary is /usr/local/sbin/binary, and this will not work. The munging in /etc/profile is an obsolete feature, please just drop it.
Hi @kzak, What are your thoughts on the /etc/login.defs change proposed in this ticket? Currently, ENV_SUPATH is commented out and I suppose "su" is using some hardcoded value.
*** Bug 2483675 has been marked as a duplicate of this bug. ***
The current hardcoded util-linux defaults (su, login, setpriv) for Fedora: _PATH_DEFPATH_ROOT "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin" So, if I understand correctly, we need to either drop "sbin" or move it to the end of the path, right? IMHO, the best would be to drop "sbin" to reduce $PATH.
(In reply to Karel Zak from comment #4) > The current hardcoded util-linux defaults (su, login, setpriv) for Fedora: > > _PATH_DEFPATH_ROOT > "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin" > > So, if I understand correctly, we need to either drop "sbin" or move it to > the end of the path, right? Right > IMHO, the best would be to drop "sbin" to reduce $PATH. According to what Zbigniew wrote in comment #1, it seems to me to confirm this, and therefore I also think it is the best choice.
I was discussing this topic with Karel offline and we agreed that util-linux needs to update the hardcoded path first, thus I'm reassigning the component