Siduction Forum
Siduction Forum => Software - Support => Topic started by: Hanisch on 2018/05/11, 15:51:54
-
Hallo,
unter Siduction 17.1.0 Patience (64Bit) und Siduction 13.2.1 December (32bit) mit dem Krusader 2.6.0 im Administrator-Modus ist es nun nicht mehr möglich, eine Datei im root-Verzeichnis - z.B. mit Shift+F4 die Datei /Test - anzulegen und dann auch abzuspeichern.
Folgende Fehlermeldungen erscheinen.
Dateianhang: Test-in-root-1.png
Dateianhang: Test-in-root-2-png
Wenn ich diese Testdatei in einem Unterverzeichnis, z.B. /etc/Test, anlege funktioniert alles wie erwartet.
Es scheint nicht möglich zu sein, eine Sicherungskopie /Test~ anzulegen.
Ich habe in Einstellungen -> Allgemein -> Betrachter/Editor -> Editor: internal editor
konfiguriert.
Beim 'internal editor' habe ich getestet:
Einstellungen -> Editor einrichten -> Öffnen/Speichern -> Erweitert -> Lokale Dateien, Haken rein (Sicherungsdatei Test~) oder Haken raus (ohne Sicherungsdatei)In beiden Fällen funktioniert es nicht.
Unter Siduction 13.2.1 December kommt abweichend von Siduction 17.1.0 Patience seltsamerweise folgende Fehlermeldung:
Siehe Dateianhang: Test-in-root-3.png
Nach dem Verwerfen der Datei /Test (0 Bytes) ist diese Datei mit 0 Bytes zwar angelegt, kann aber nicht bearbeitet (F4) und danach gespeichert werden.
Unter Krusader 2.4.0 war das problemlos möglich.
Auch unter Kubuntu 18.04 (64Bit) und Kubuntu 17.10 (32bit) funktioniert das mit dem Krusader 2.6.0.
Allerdings tritt das Problem auch unter der Distribution Manjaro mit dem Krusader 2.6.0 auf.
Es funktioniert also nicht, wenn eine Datei mit F4 editiert werden soll, die im Root-Verzeichnis / liegt.
Das sieht mir wie ein Bug im 'internal editor' in Krusader 2.6.0 aus.
Das hier funktioniert auch nicht mehr:
~$ kdesudo kate
Executing Kate as root is not possible. To edit files as root use:
SUDO_EDITOR=kate sudoedit <file>Dieses mickrige 'sudoedit' ist kein vollwertiger Ersatz, etwa für 'kdesudo ...'.
Gruß
Ch. Hanisch
-
Beschwerden bitte bei KDE abladen, nich hier - das ist so gewollt von denen. Und wir werden das so akzeptieren und exakt gar nichts dagegen tun.
-
Richtig, KDE ist die richtige Adresse... aber auch für mich ist es ein unmögliches Verhalten seitens KDE.
@Alf: bringen da bugreports was, oder was schlägst Du vor?
-
Öffentlichkeit hilft immer.
-
@Lanzi - an und für sich ist das gar nicht so falsch, was die Buben machen - nur dass diese Änderung von einem Software-Extremisten durchgezogen wurde (um genau zu sein Martin Flöser, früher Grässlin) - Mein Kritikpunkt daran ist nicht, dass diese Änderung gemacht wurde, sonder nur das wie. Auf Deutsch: Der Scheiss hat optional zu sein, default auf das neue Verhalten. So wie es momentan implementiert ist, ist das einfach nur armselig. (So, das war meine für die breite Öffentlichkeit sehr entschäfte, gradezu sanftmütige Beurteilung dieser Aktion).
Und hier meine private Meinung dazu, mal unzensiert und nicht politisch korrekt. Und seit der Zeit, wo ich das verzapft habe, hat sich nichts an meiner Einschätzung geändert:
2018-01-06 <agaida> ... ich hätte nie gedacht, ... das viele KDE-Entwickler das Hirn komplett ausschalten und das in der härtesten und schädlichsten Variante durchziehen. Solche Handlungsweisen war ich zuvor eigentlich nur von exGrässlin gewohnt.
2018-01-06 14:40:41 <devil> agaida: nu sei mal liep zu dem
2018-01-06 14:42:38 <agaida> erm - wer so was aktiv vorantreibt und beführwortet, der kann nicht auf Verständnis und Wohlwollen meinerseits hoffen
2018-01-06 14:42:41 <agaida> https://phabricator.kde.org/D4634?id=11412
2018-01-06 14:42:41 <noctua> [ ⚙ D4634 Disallow executing kate and kwrite as root on Linux ]
2018-01-06 14:43:27 <agaida> den erachte ich als schädlich - und da wird sich auch so schnell nichts an meiner Meinung ändern.
2018-01-06 14:44:25 <agaida> sorry, so was ist mit mir nicht drin, da sind dann Grenzen erreicht und weit überschritten
2018-01-06 14:48:56 <agaida> und auch wenn ich zu meintwegen als Beispiel dat Kevin K. meine eigene Meinung habe - der mag manchmal nicht der Hellste sein oder kommt so rüber, aber als Upstream so einen Scheiss zu fabrizieren exponiert einen praktisch für harte Angriffe. Und da ist dat Mattin, weinerlich wie er ist, nicht der Richtige für. Man wünscht sich manchmal, dass der Shuttleflieger damals noch mal nachgelegt hätte, das hätte zwar die KDE-Entwicklung zurückgeworfen, aber langfristig das Thema Grässlin/Flöser final gelöst
-
Nachtrag: All mein Gerante hat jemand hüpsch zusammengefasst und so formuliert, dass es nicht die potentiellen Adressaten vor den Kopf stößt. Dem ist erst ma so nichts mehr hinzu zu fügen:
https://phabricator.kde.org/D12732 Implement a more user-friendly run-as-root-or-sudo behavior
-
You can always use sftp://root
.............. runs .......... fast ........... ducks .......... falls
-
After reading the arguments in the dolphin bug again i think it is a good idea to share the Summary of
https://phabricator.kde.org/D12732
I'd like to revisit the issue of not allowing Dolphin to run with elevated privileges, and make the case that the way this change was implemented was user-hostile and sub-optimal. I would also like to propose an alternative in patch form.
Ideological/correctness arguments
- It's not appropriate for software at the DE level to make judgments about how the user has chosen to run it or what kind of user account they're using. In terms of the OSI model, this would be like a web app on the Application layer refusing to run when the Transport layer is TCP, or the Network layer is IPSec. If there's a security vulnerability at the X11 level, it should be fixed there.
- There is no reason to prevent using Dolphin as the root user (not sudo). Using Dolphin with the root user account is no more insecure than any other GUI software executed as the root user, since X11 is already being run as the root user. The current implementation fails to make this distinction and therefore aggravates people who need or want to use KDE Plasma with the root user.
Practical arguments
- Distros like Kali use KDE Plasma and boot to a root GUI session by default (and by design). For users of this distro, Dolphin simply doesn't work at all. The same goes for recovery distros the boot into the root user. It's not reasonable to entirely break these use cases.
- Since the feature was disabled, we've received a neverending stream of criticism that demoralizes KDE developers, takes up the time of KDE bug triagers, and generates negativity on social media that discourages people from using our software.
- openSUSE has patched out the change; when a major enterprise distro undoes your work, it might be worth listening to them and considering whether the change might have been ill-considered/
Usability and user-friendliness arguments
- It is user-hostile to disable a feature before its replacement (PolicyKit support in KIO) is available.
- The current method of implementation is user-hostile: a message is only printed to the console, and if a GUI method is used to run Dolphin with sudo or as root, there is no indication of why it doesn't work. Dolphin just looks broken, and we look bad.
- Our userbase largely consists of technically competent users who hate being told that they can't do something "for their own good" that they know is technically possible. We haven't won any friends with this change.
For all of these reasons, this patch reverts the previous implementation that disabled running from root and with sudo, and instead replaces it with more nuanced check that distinguishes between when Dolphin is run as the root user and when it's run as the current user via sudo. It displays an orange warning message in the GUI instead of prohibiting the program from running.
Once PolicyKit support is enabled in KIO and released to users, I think it might be reasonable to once again prohibit running Dolphin with sudo (but not as root) as long as we provide a GUI message to cover the case where Dolphin-with-sudo is launched via a desktop file, as is common with many old "open this folder with administrator privileges" add-ons that people may still be using.
-
I hope this will be considered for dolphin, kate, kwrite and other applications that suffer from that issue.
-
+1