Hey, just a quick question. I wrote a script that calls kdesu to start a systemd service prior to launching an app (virt-manager) and realized that kdesu is not in my normal $PATH. It was easy enough to find so it’s not really a big deal, I was just wondering why this is the case? Is it something some distros do, but others do not or is it a specific decision by the kde dev team? I’m just curious is all.
1 Like
Apparently, this was always supposed to be the case. Still don’t really get it though.
It’s a distro thing, in adherence with linux standards. It’s not something a normal user should need to use, so it’s in the super user’s binary directory (eg /usr/sbin) which is not in the path for normal users.
You can look up ‘linux FHS sbin’ in your search engine to learn more.
1 Like
How do you figure? I am a normal user and I am using it so… Also, /usr/sbin on my system is just symlink to /bin which itself is a symlink to /usr/bin, which does exist in $PATH. On plasma 6 the path for kdesu is /usr/lib/kf6 no any bin directories. Adding it to $PATH is simple enough, but my question still remains.
It’s something some distros do. You need to ask your distro, KDE doesn’t have control over where distributions decide to install binaries or what their default PATH is.
Like pallaswept said, usually binaries in /sbin are things users without privileges aren’t supposed to touch (reversely, they’re usually available once you attempt to run them with sudo).
1 Like
Well, after reading the kde su manual, this doesn’t seem distro specific at all (the examples look like this: $(kf5 -config --path libexec)kdesu ). So, I do not believe what you are saying is correct.
Again, not really a huge issue, I was just curious about the rationale behind the whole thing. I mean a regular user would probably have a hard time finding/using it is what I was thinking.
If you ran that search you’d know we are.
I think maybe some wires got slightly crossed here? 
@Herzenschein and @pallaswept are 100% correct that in general, $PATH decisions are made by the distribution, and that part of that process can include whether or not to try to separate out privileged binaries from “regular user” ones.
On the other hand - and folks who were part of this history can give far better context, I’m sure - looking back at the kdesu code history would tend to indicate that the installation location was intentional, at least back when kdesu was in its early days:
- It was first built to be used as part of a framework, rather than a directly user-executed binary, so it was placed outside of the path: Add a bit of documentation for how to use --attach (f6438408) · Commits · Plasma / KDE CLI tools · GitLab
- It ended up being used as a CLI tool, and not part of the framework, so it shifted KDE projects: Move kdesu to kde-cli-tools (109a8384) · Commits · Plasma / KDE CLI tools · GitLab
- The binary location hasn’t conceptually changed since back then, just updated to keep current with other KDE components (ex. Fix libexec install dir (b95a2959) · Commits · Plasma / KDE CLI tools · GitLab)
I may very well be reading all that wrong, but I thought it was an interesting historical look back into how things worked 20+ years ago - there’s a reference implying that maybe Windows support was going to be in scope for the framework at some point: Projects/kdesu - KDE TechBase …shades of KDE for Windows!
1 Like
On Neon, I have kdesu installed in /usr/lib/x86_64-linux-gnu/libexec/kf6/kdesu - which definitely implies its a framework tool and users are not expected to invoke it.
While on Fedora, its in /usr/bin/kdesu which is very much in the system’s PATH and looks like a standard user tool.
So it is distro-specific, though it looks like that according to the manufacturer (KDE) it isn’t supposed to be in the PATH.
BTW - the correct way to start a system systemd service from user context is to use systemctl start {servicename} which will use a polkit graphical dialog to ask for the password (if needed), and will provide a much better context to the user than what kdesu does. Another systemd alternative - that can be used to run other commands as root, not just manage the status of services - is systemd-run - the graphical prompt from that is much less useful in explaining what is going on, though.
1 Like