Bugzilla – Bug 450203
[KDE 4.4] File Manager - Super User Mode can't launch KWrite
Last modified: 2015-02-18 21:34:30 UTC
When right-clicking on a text file in File Manager - Super User Mode, selecting 'Open With > KWrite' produces an error dialog: 'Sorry Dolphin' 'KDEInit could not launch '/usr/bin/kwrite'.' Performing the same action in Dolphin as a normal user works OK. (Tried with /etc/networks in both applications). Listing for /usr/bin/kwrite: # ll /usr/bin/kwrite -rwxr-xr-x 1 root root 6416 Nov 25 04:37 /usr/bin/kwrite File Manager - Super User Mode was started through the (classic style) menu Start > System > File Manager > File Manager - Super User Mode.
Got same effect when starting Dolphin from a root console.
I've the same problem, it's really annoying.
*** Bug 466132 has been marked as a duplicate of this bug. ***
https://bugs.kde.org/show_bug.cgi?id=75492#c29 says there are reasons why this happens, we'll have to solve it for KDE 4.3 now.
This says its resolved in Novel Bugzilla, but I'm experiencing this as normal user with KDE 4.2.4 release 2, Dolphin 1.2.1 on openSUSE 2.6.27.23-0.1-default. When I click on a .sql document I get error KDEInit could not launch 'konsole'. Then get blank GUI that say user name: Kate for title and another GUI with user name: Kate with the sql displayed. My file association for .sql is : Kate Kwrite OpenOffice write I did not change the file associations except for order of Kate and Kwrite. I also reported this on Bugzilla. Reported as comment on KDE bug 75492.
Reopen see comment #5
Can confirm, still broken on 4.3rc1
*** Bug 516092 has been marked as a duplicate of this bug. ***
Still reproducible with exact same behavior on 11.2 DVD 64-Bits Milestone 6 with KDE4.3. Will check on the KDE side and comment bug listed there as well. It's very annoying as I have to go in konsole all the time to edit as root.
*** Bug 540239 has been marked as a duplicate of this bug. ***
Just a follow-up to confirm it's still reproducible with exact same behavior on 11.2 DVD 64-Bits Milestone 8 with KDE4.3. Will update again on the KDE bugs side.
*** Bug 546386 has been marked as a duplicate of this bug. ***
the problem when it is present in openSUSE 11.2 RC2 user-mode superuser do not edit the files (like fstab, xorg.conf, etc. etc.) bud problem! bye by Andrea
*** Bug 553434 has been marked as a duplicate of this bug. ***
*** Bug 523643 has been marked as a duplicate of this bug. ***
Still present in openSuSE 11.2 final. This is marked as being present in x86-64, but it is also present in the x86 release. Additional information: Attempting to launch Kwrite from the Super-User Mode file manager fails with the message: KDEinit could not launch '/usr/bin/kwrite' Launching Kwrite from the bash prompt as the super user starts Kwrite, but attempting to use the File -> Open dialogue gives the following errors: Kwrite displays: Could not start process Cannot talk to klauncher: Not connected to D-Bus server. Konsole displays: kdeinit4: preparing to launch /usr/lib/libkdeinit4_klauncher.sp kdeinit4: Communication error with launcher. Exiting This really does need to be fixed.
Correct, still reproducible all the time, no matter the graphical editor chosen. In konsole you can try with 'kdesu kwrite file.name'. It works fine, but it forces the user to use command line, which isn't what the purpose of a graphical interface is for. The bug at KDE as gone a long way. https://bugs.kde.org/show_bug.cgi?id=75492
Strangely enough it works as expected with super-user Krusader. Maybe that's useful info, dunno. The Krusader super-user .desktop-file is a bit different, but using that model for Dolphin still doesn't work.
Good grief, the bug on the KDE bug tracker is 6 years old!
Indeed. I don't know if they are necessarily related though, because everything worked fine with openSUSE 10.3. Since KDE4 (11.0 and I confirm for 11.1+) it's not working in openSUSE.
This bug still appears in 11.3 MS1 with kde 4.4.
It starts to get annoying not to be able to open simple files (any file) using File Manager Super User Mode. Yes there exists a few workarounds, but I have found that these workarounds are not perfect replacements. For example, if you browse from File Manager in your root partition and then want to open a root text file, you need to use Single User mode file manager and install a Root Service Menu. Fine there. But there exist some folders (especially in /var) you cannot even access with Single User Mode file manager, so you need Super User just to browse the folders. But Super User does not have the Root Service Menu and cannot open files! So you end up installing the Root Service Menu for... Root User! Or doing everything from command line, which takes the graphical user out of its "natural" world.
My workaround is adding a Konq1ueror-su to the menu editor with command konqueror --profile filemanagement and under Advanced "Run as other user" - root
I have some more information if it is of any use. If I open a terminal and become super-user and then (for example) open a file as follows: kwrite /etc/X11/xdm/Xaccess The file opens and I can edit it and save it. I get the following feedback on launch: kdeinit4: preparing to launch /usr/lib/kdeinit4_klauncher.so kdeinit4: Communication error with launcher. Exiting! The program seems to open fine however. On exit I get one additional line of feedback: QThreadStorage: Thread 0x8050000 exited after QThreadStorage 2147483639 destroyed
This bug has been open in 2008. Does anyone know why a Major-P2 bug is still open 16 months later? I mean has someone pinpointed the culprit or developers are still working on it? What should we expect in the next suse releases about this bug? Just trying to get updated on the status. tnx
There seems to be a simple fix to this problem, suggested by Wilson_Phillips here: http://forums.opensuse.org/applications/434206-cannot-open-files-dolphin-superuser.html#post2129001 I can confirm that a file such as this: [code] #!/bin/bash # Allows root to open windows on your display. Example: KWrite and Kate xhost +local:0 [/code] when made executable and placed in the user's ~/.kde4/Autostart directory, fixes the problem cited in this bug, plus that of any other program launching with root's permission. The same file, when moved to the /etc/X11/xinit/xinitrc.d/ directory (and making it root-owned, with permissions 755) also fixes this bug. The latter location would seem to be the better of the two to use as the solution. This would probably be applicable to openSUSE 11.3 as well. KDE Bugzilla also has a similar bug in #190532.
(In reply to comment #26) > # Allows root to open windows on your display. Example: KWrite and Kate > xhost +local:0 The problem with xhost is that it allows _every_ user (with a login on your machine, even if he logs in over SSH) to access your X server. This means not only things like "display kwrite in superuser mode", but can also mean things like "run an (invisible) keylogger and steal some passwords". Nice security problem :-( which means xhost is not recommended... (It might be acceptable as workaround if you are the only user on your computer.)
Would the security concern still apply if the file is located in ~/.kde4/Autostart folder?
(In reply to comment #28) > Would the security concern still apply if the file is located in > ~/.kde4/Autostart folder? Yes. It doesn't matter how/from where you call "xhost +local". As soon as it is called, every local user (including SSH logins etc.) can access the X server. As I said: it might be a _workaround_ on systems with only trusted users (or just one user at all ;-) xhost +local should never be a default setting, and I'm quite sure the security team will tell you the same if you ask them.
Well I can confirm it is working fine. Actually I wonder if inserting 'xhost +local:0' line in .bashrc would do the job as well, I may try for fun. I will keep that workaround cuz I am the only user using this machine and I log on directly on the machine with a PW. There are no other user created. I am outside a network (other than connected on internet through a secured router via cable). tnx
> As I said: it might be a _workaround_ on systems with only trusted users > (or just one user at all ;-) > xhost +local should never be a default setting, and I'm quite sure the > security team will tell you the same if you ask them. That seems entirely reasonable. It remains to see how we can get Dolphin (and Konqueror) to launch applications such as KWrite, Kate, etc without running afoul of this X-server display problem. If I launch Konqueror in Super User Mode and select Tools-> Execute Shell Command, then enter: [code] export XAUTHORITY=/home/$USER/.Xauthority; kate filename [/code] 'filename' is opened in Kate without any X-server display errors. (I couldn't find a way for Dolphin to execute Kate from within.) Without the 'export' command, Konqueror usually produces this error: No protocol specified kate: cannot connect to X server :0.0 The fix would seem to be to make the 'Open With' function run the 'export XAUTHORITY=/home/$USER/.Xauthority' command before executing the 'Open With' application. This method should satisfy security concerns, as only the person with the root password will ever get to execute this function. This authority is not persistent, as any subsequent attempt to 'Open With' Kate without the 'export' command fails in the normal manner. This suggests that the authority to operate in the user's display ceases when the application is closed. That's to be expected, as the exported $XAUTHORITY value dies when the shell closes. This method also works when launching Kate through an 'Open With' function within Konqueror that's running as a normal user. That means that any changes introduced into Konqueror (or Dolphin) to cater for fixing the problem while running as root, shouldn't upset normal operation when running as a normal user. This issue has to be solvable. Konsole, for example, in Super User mode, has no trouble launching 'kate filename'. It doesn't experience this problem. Yet, like Dolphin (and Konqueror) Super User Mode, it is an application running with elevated root privileges in the user's X-server display.
Problem is still present in openSuSE 11.3, Milestone 5. Can we get a fix on this P2 bug?
Still present in openSuSE 11.3, Milestone 6. Should I create a new, separate bug report for SuSE 11.3?
You can simply move the bug to the latest version where it occurs. I have done this now.
Fixed.
Where is it fixed? I still have this bug in 11.3 Milestone 7
Since the fix was posted after 11.3 Milestone 7 was released, it won't be there. It should appear in the next release (Jun 17 - RC1).
Thank you. Sorry. My fault.
Could we get this fix backported to 11.2 Geoff? It's still really annoying on that release...
Re comment #39: sorry I can't do anything about that; I'm just a bug reporter, not the package maintainer.
Just checking in on this one... I take it the fix isn't forthcoming at this time?
Check the status at the top of this bug report. It shows Status: RESOLVED; Resolution: FIXED. I do not see the problem in 11.3 final release, nor 11.4 M3.
Yes, but the fix hasn't been backported to 11.2 Geoff - it's still an issue there.