Description of problem: https://cgit.kde.org/kdesu.git/tree/src/stubprocess.cpp#n166 hardcodes the following PATH prefix for root: if (m_user == "root") { if (!path.isEmpty()) { path = "/sbin:/bin:/usr/sbin:/usr/bin:" + path; } else { path = "/sbin:/bin:/usr/sbin:/usr/bin"; } } Not only is this duplicating the paths (since UsrMove), but also, most crucially, the /usr/local/* paths are missing. Hence, it is not possible to override system binaries with newer or modified versions in /usr/local. Please change this to: if (m_user == "root") { if (!path.isEmpty()) { path = "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:" + path; } else { path = "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"; } } Version-Release number of selected component (if applicable): kf5-kdesu-5.36.0-1.fc25 kf5-kdesu-5.38.0-1.fc26 kf5-kdesu-5.38.0-1.fc27 kf5-kdesu-5.39.0-1.fc28 How reproducible: Always Steps to Reproduce: 1. kdesu -t sh -c 'echo "$PATH"' 2. Compare with su - -c 'echo "$PATH"' Actual results: The output of step 1 starts with "/sbin:/bin:/usr/sbin:/usr/bin:", not honoring /usr/local. The comparison step 2 outputs a sensible path. Expected results: Step 1 outputs a path equivalent to step 2. Additional info: I found this while testing my kannolo-root-unlocker, but there are certainly other use cases affected, and the defaults should be consistent across the distribution.
/usr/local* should _never_ be ahead of anything in a secure component, furthermore, the original paths are in the order in which they should be trusted most to least. A su program should *explicitly* _NOT_ follow the $PATH defaults, as those can be d exploited, overridden, etc. This should definitely not be overridden or patched as it could have far reaching security consequences. Bottom line: /usr/local should never be honored unless explicitly set as $PATH after root login.
> /usr/local* should _never_ be ahead of anything in a secure component, Why? /usr/local is writable only by root. I fail to see any security risk in having it first. And /usr/local is ALREADY ahead of /usr in the default path for root in Fedora. This would just follow the global distribution policy. > furthermore, the original paths are in the order in which they should be > trusted most to least. From the user's point of view, they are not. The binaries installed by the root user ought to have priority over distro-provided ones. And the rest of Fedora ALREADY honors this by policy, only kdesu gets it wrong. > A su program should *explicitly* _NOT_ follow the $PATH defaults, as those can > be d exploited, overridden, etc. That's why my proposal is to only replace the hardcoded PATH setting with another hardcoded PATH setting that matches the Fedora defaults. I am NOT proposing to honor any PATH the non-root user provides. > This should definitely not be overridden or patched as it could have far > reaching security consequences. Huh? kdesu is just a wrapper for su. You always have to enter the root password and you can run any commands. This is NOT sudo, where you can whitelist selected commands to run with the user password (and by the way, the recommended policy there is to only whitelist commands with full path, to avoid exactly this issue, but that is getting off topic). And in addition, as I already wrote above, /usr/local is writable only by root, so a non-root user cannot dump malicious executables there. > Bottom line: /usr/local should never be honored unless explicitly set as $PATH > after root login. This is not workable: kdesu does no do root login, it runs one command as root, so the $PATH is needed to even just find the command. So, to sum it up, I do not understand your objection at all.
Well it's unfortunate that Fedora screwed this up so badly. The kdesu defaults are sane, as they apparently knew what they were doing. /usr/local should never be part of $PATH unless it is explicitly set by manual configuration, IMHO. > From the user's point of view, they are not. The binaries installed by the root user ought to have priority over distro-provided ones. I disagree. If people want that they should both `make install` or whatever they're doing these days and also configure it in their dotfiles. It shouldn't be implicit that compiled and manually installed programs are present in their path. > That's why my proposal is to only replace the hardcoded PATH setting with another hardcoded PATH setting that matches the Fedora defaults. If you're going to replace it with something, replace it with something that respects the defaults dynamically. Then I can expend my energy in getting only one thing changed. > Huh? Meaning that it shouldn't have different behavior from su - talk about "user expectations." If you're going to do anything at all, don't hard code it so that it needs to be inspected later on. > So, to sum it up, I do not understand your objection at all. Do not hard code anything; especially path parameters that the sysadmin won't expect to be hard coded. (I would not expect this to ignore an explicit path configuration if I were asked this question, and I would venture most people wouldn't either)
> Well it's unfortunate that Fedora screwed this up so badly. The kdesu defaults > are sane, as they apparently knew what they were doing. > > /usr/local should never be part of $PATH unless it is explicitly set by manual > configuration, IMHO. I disagree. The user expectation is that if they go through the trouble to install an application locally, it actually works, even if some older version is installed from packages. They obviously compiled the other version for a reason. > > From the user's point of view, they are not. The binaries installed by the > > root user ought to have priority over distro-provided ones. > > I disagree. If people want that they should both `make install` or whatever > they're doing these days and also configure it in their dotfiles. Dotfiles are definitely the wrong place to set up systemwide installations. If anything, it should be in systemwide config files. But I don't see why the directory that the distribution explicitly provides for custom installations by the system administrator should not be set up there out of the box (as it currently is). > It shouldn't be implicit that compiled and manually installed programs are > present in their path. Again, why? If you go through the trouble of compiling and installing a program, surely you actually want to use it. > > That's why my proposal is to only replace the hardcoded PATH setting with > > another hardcoded PATH setting that matches the Fedora defaults. > > If you're going to replace it with something, replace it with something that > respects the defaults dynamically. Then I can expend my energy in getting only > one thing changed. That would be the ideal solution, but that's not how kdesu works now. If we remove the PATH override for root entirely, bin and sbin will be in the wrong order. If we make it use "su -" instead of "su", the current directory will be affected. We would probably have to run something like: su - -c 'echo "$PATH"' (which of course requires the root password) and capture the output. > Meaning that it shouldn't have different behavior from su - talk about "user > expectations." Different behavior from "su -" is exactly what this bug is about. > If you're going to do anything at all, don't hard code it so that it needs to > be inspected later on. But it's not trivial to do the right thing. See above. > > So, to sum it up, I do not understand your objection at all. > > Do not hard code anything; especially path parameters that the sysadmin won't > expect to be hard coded. (I would not expect this to ignore an explicit path > configuration if I were asked this question, and I would venture most people > wouldn't either) I actually agree with you there, it is just hard to do right. Where we disagree is that, IMHO, if we are hardcoding something, it should at least match the distrowide default.
Interestingly, sudo defaults to the same wrong path as kdesu (I call it wrong because listing both /(s)bin and /usr/(s)bin makes no sense at all after UsrMove), which is probably where kdesu copied it from. Though, at least in sudo, it is configurable in /etc/sudoers.
I filed bug #1506582 against sudo.
It will not matter for kannolo-root-unlocker because I am changing it to use /usr/sbin instead of /usr/local/bin, so kdesu will find the patched binaries out of the box (it is also cleaner to not write to /usr/local in a package, the only drawback is that if you try running the executables as root with a user PATH, the patched ones will not be found), but I still strongly believe that /usr/local/(s)bin ought to be in the front of the search path.
See also https://pagure.io/fesco/issue/1788 .
And to clarify one thing: as I wrote on IRC, just removing the prepending with no replacement is not going to do the right thing, please do not do that! (This was the first thing I, too, thought should be done, but I realized that it does not work correctly.) The path for users has /usr/bin before /usr/sbin. The path for root has /usr/sbin before /usr/bin. This distinction is important. Just using the PATH from the environment as is breaks that.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.