Hi,
since both KDE upstream and the Fedora KDE SIG refuse to fix the regression that Dolphin, KWrite, and Kate can no longer be run as root, I have decided to write a small metapackage that automatically applies the binary patch to fix the issue.
The patch that is applied is the 's/getuid/getpid/g' hack, see: https://www.spinics.net/linux/fedora/fedora-kde/msg19018.html for an explanation of how it works.
The patched executables are written to /usr/local/bin. The metapackage uses file triggers so that the patched version is automatically updated when the original copy in /usr/bin is updated from the system package. While it would be possible in principle with this method to apply the patches in place in /usr/bin, I have decided against it, for 2 reasons: 1. integrity checks such as rpm -Va would fail on the patched executables, and 2. delta RPMs would fail because the original RPM could not be reconstructed. Writing the patched executables to a different directory avoids this issue.
After installing this package, e.g., "kdesu kwrite" should just work again.
You can get the package from the Kannolo Copr: https://copr.fedorainfracloud.org/coprs/kkofler/kannolo/
Source code: https://svn.calcforge.org/viewvc/kannolo/trunk/packages/kannolo-root-unlocke... Direct package link: https://copr.fedorainfracloud.org/coprs/kkofler/kannolo/package/kannolo-root...
Enjoy!
Kevin
On 08/17/2017 04:35 AM, Kevin Kofler wrote:
Hi,
since both KDE upstream and the Fedora KDE SIG refuse to fix the regression that Dolphin, KWrite, and Kate can no longer be run as root, I have decided to write a small metapackage that automatically applies the binary patch to fix the issue.
Hear hear! Thank you.
Fedora KDE-SIG (and upstream) should really rethink on this stupid decision.
Syam
Syam Krishnan wrote:
Fedora KDE-SIG (and upstream) should really rethink on this stupid decision.
FYI, code-of-conduct warning (please try harder to assume good intentions from all those involved).
And word of advice: if you're trying to appeal to someone to change minds, name-calling usually doesn't work all that well.
-- Rex
On 08/22/2017 10:11 PM, Rex Dieter wrote:
Syam Krishnan wrote:
Fedora KDE-SIG (and upstream) should really rethink on this stupid decision.
FYI, code-of-conduct warning (please try harder to assume good intentions from all those involved).
And word of advice: if you're trying to appeal to someone to change minds, name-calling usually doesn't work all that well.
I know what you mean....
But I would like to point out what I see as a fine distinction. Syam called the decision "stupid". He did not call the people making the decision "stupid". So, IMO, there is no code of conduct issue. I don't know about you, but even if I disagree with someone if they call my choices/decisions stupid as long as they don't call me stupid I don't take offense. It also helps if they, and they usually do, give explicit reasons for their opinion.
Ed Greshko wrote:
On 08/22/2017 10:11 PM, Rex Dieter wrote:
Syam Krishnan wrote:
Fedora KDE-SIG (and upstream) should really rethink on this stupid decision.
FYI, code-of-conduct warning (please try harder to assume good intentions from all those involved).
And word of advice: if you're trying to appeal to someone to change minds, name-calling usually doesn't work all that well.
I know what you mean....
But I would like to point out what I see as a fine distinction.
...
IMO, there is no code of conduct issue.
I didn't say it was a violation. I said "warning". This distinction you make is that people are potentially encroaching dangerously close to (but not yet crossing) the line of what could be considered a clear violation.
I personally would like to encourage a decorum here that stays as far from that line as reasonably possible. That's my expectation of ideal interaction here.
-- Rex
-- Rex
On 08/22/2017 07:41 PM, Rex Dieter wrote:
Syam Krishnan wrote:
Fedora KDE-SIG (and upstream) should really rethink on this stupid decision.
FYI, code-of-conduct warning (please try harder to assume good intentions from all those involved).
And word of advice: if you're trying to appeal to someone to change minds, name-calling usually doesn't work all that well.
Sincere apologies upfront if I offended anyone. I have nothing but huge respect for KDE and Fedora KDE-SIG people, especially Rex & Mr. Kofler.
As Ed pointed out, I called the "decision" stupid and not the people involved. The upstream people who made this decision are in no way stupid, but definitely a bit arrogant, in my opinion. With these kind of design decisions shoved down the users' throats, they are approaching the GNOME culture.
I would still urge Fedora-SIG to rethink on this. Please let your users make these decisions. I'd understand if the application presents a warning when run as root. But simply exiting the application (without even telling the user why!) is indeed "not-very-smart" in my books.
Thanks,
On Tuesday, 22 August 2017 11:46:02 AM AEST Syam Krishnan wrote:
On 08/17/2017 04:35 AM, Kevin Kofler wrote:
Hi,
since both KDE upstream and the Fedora KDE SIG refuse to fix the regression
that Dolphin, KWrite, and Kate can no longer be run as root,
I have decided to write a small metapackage that automatically applies the binary patch to fix the issue.
Hear hear! Thank you.
Fedora KDE-SIG (and upstream) should really rethink on this stupid decision.
I've kinda stayed out of this debate, but when looking at the details, I also cannot find any logical reason to the change as it exists in the upstream source.
It simply doesn't make sense to exit silently when run as root.
I wouldn't quite call it 'stupid' - but I would call it short sighted / problematic.
A better solution would be to pop up a dialog stating "This is being run as root and could be dangerous".
First of all, I'm just an user.
A better solution would be to pop up a dialog stating "This is being run as
root and could be dangerous".
This is the best apporach, Why don't take it?
Br,
Eduard Lucena wrote:
A better solution would be to pop up a dialog stating "This is being run as root and could be dangerous".
This is the best apporach, Why don't take it?
Because the upstream developer thinks even bringing up a dialog as root is already too big a security risk (even though there's clearly nothing you can do through the known attack vectors – remote-controlling the UI – with a simple OK-only dialog) and so decided to print the error only to stdout, which goes nowhere under kdesu.
Unfortunately, upstream is being very unpragmatic here, both by not allowing a way to proceed anyway and by the user-unfriendly way the error is being reported.
Kevin Kofler
Hi,
an updated version is now available: It has come to my attention that version 1 correctly unlocked root for KWrite and Kate, but not for Dolphin. This is because Dolphin uses the "kdeinit hack", so the getuid check is not in the dolphin binary, but in the libkdeinit5_dolphin.so library.
Version 2 now: * patches libkdeinit5_dolphin.so with s/getuid/getpid/g into libkdeinit5_d0lphin.so, and * patches /usr/bin/dolphin with s/libkdeinit5_dolphin.so/libkdeinit5_d0lphin.so/g into /usr/local/bin/dolphin.
This should make "kdesu dolphin" work, too. (Please note that using kdesu means that the library is never actually loaded by kdeinit5, so it should not matter that the name of the libkdeinit5_d0lphin.so library does not match the name of the binary, as long as the binary is linked to the correct library.)
Kevin Kofler
I finally got around to doing some testing and debugging in a VM on this, and there is now an important change:
I wrote in the announcement:
The patched executables are written to /usr/local/bin.
As of version 3 released today, the patched executables are instead written to /usr/sbin.
This change was necessary due to the hardcoded search path in kdesu: https://bugzilla.redhat.com/show_bug.cgi?id=1506422 . I was not aware that kdesu does not follow the Fedora policy of having /usr/local/bin in the PATH (and neither does sudo, for what it's worth, whereas login shells as root do, what a mess!).
Advantages of the change: + kdesu now finds the executables, so, e.g., "kdesu kwrite" really just works. With previous versions, only "kdesu /usr/local/bin/kwrite" or "kdesu `which kwrite`" actually worked. + The package no longer writes anything to /usr/local, which should not be written to by packages.
Drawbacks of the change: - Anything that tries to use the regular user PATH while running as root will not work, because it will find the unpatched binary in /usr/bin first. (Normal users now get the unpatched binary, but for them, it will work fine.) - In particular, something like "kdesu `which kwrite`" will also no longer work.
If you are not happy with those drawbacks, you can add symlinks: ln -s /usr/sbin/{dolphin,kwrite,kate} /usr/local/bin/ I decided against doing this in the package because it is cleaner to not mess with /usr/local in a package. (I did not realize at first that sbin can be used for this purpose, or I would have already done it before.)
I verified in a VM that the new version really works as advertised. Upgrades from the old package also do what is expected. (They remove the binaries from /usr/local/bin and recreate them in /usr/sbin.)
Enjoy!
Kevin Kofler
-
Ed Greshko -
Eduard Lucena -
Kevin Kofler -
Rex Dieter -
Steven Haigh -
Syam Krishnan