Running Dolphin under user other than root or currently logged in user.

If I am logged in to a KDE session as user “joe” and want to use Dolphin to access “john”'s files and startup other programs to edit “john”'s files, etc., a simple “kdesu dolphin” does not work. It gets errors like “Could not start process. Cannot talk to klauncher: The name org.kde.klauncher was not provided by any .service files.”

If I use the KDE startup menu and go to “Switch User” to start a new parallel session under user “john” so that I have two active sessions under users “joe” and “john”, then a simple “kdesu dolphin” will work. However, that is a very clumsy and awkward way of getting this to work.

Does anyone know of a more streamlined and automatic way to get this done?

On 10/26/2015 03:06 AM, xode0000 wrote:
>
> If I am logged in to a KDE session as user “joe” and want to use Dolphin
> to access “john”'s files and startup other programs to edit “john”'s
> files, etc., a simple “kdesu dolphin” does not work. It gets errors
> like “Could not start process. Cannot talk to klauncher: The name
> org.kde.klauncher was not provided by any .service files.”
>

This works on my system (Leap) with Plasma 5, I am able to start dolphin using kdesu.
What version of openSUSE are you using? Do you have any non default repos (zypper lr -uP)?

Seems https://bugs.kde.org/show_bug.cgi?id=199209 and https://bugs.kde.org/show_bug.cgi?id=165268 are related to this.


openSUSE Leap (42.1) 64 bit
Plasma 5

Use the “File Manager - Super User mode” entry in the application menu.
“kdesu dolphin” doesn’t always work, that’s why we replaced it with “kdesu dbus-launch dolphin” years ago…

Just tried what you suggested (and I had also tried it before as well, and in fact had copied the menu entry for the root file manager to create the menu entry for the “john” file manager having changed only what user to run under to “john” for the menu entry for “john”). I still get from dolphin the error “Could not start process. Cannot talk to klauncher: The name org.kde.klauncher was not provided by any .service files.” It appears that many things need to be started and set up before even a simple file manager can be used. Starting a new parallel session under user “john” obviously does all of those things and apparently all of those things are done for root as well whenever any user session is started, so a file manager under root will start up properly.

However, what I need here is a file manager that runs under user “john” since it will be “john”'s files I will be editing and I would like something a lot more streamlined than having to start a new parallel session under user “john” whenever I simply want to use a file manager for user “john”.

Well, it’s not about a “simple file manager”, but it’s about a KDE application that needs other KDE stuff to be running.

Starting a new parallel session under user “john” obviously does all of those things and apparently all of those things are done for root as well whenever any user session is started, so a file manager under root will start up properly.

Of course.
If you start a “parallel” session, everything needed is running in that session.

For root it is a bit different, as root has all permissions to run things in your user’s session (if you permit it to open windows that is, e.g. by using kdesu)

However, what I need here is a file manager that runs under user “john” since it will be “john”'s files I will be editing and I would like something a lot more streamlined than having to start a new parallel session under user “john” whenever I simply want to use a file manager for user “john”.

Use a simple file manager then.
mc e.g.

I hope you understand that that is completely contrary to the concept of a multi-user system where every user is protected against the actions from other users.

Thus it is a build-in feature that user pete can not edit user john’s files. Except when username john allows the needed access by setting certain permissions (like write access) to the files and the directories (like search access) in the path to those files.

Thus, yes it is normal that user John should login to edit his/her files. That is by design.

And talking about “I” (in phrases like “I will be editing”) has no meaning for the system. The system only knows the userids that are defined (with their usernames) and if they are loged in. And which process is owned by which userid and thus which process may do things to which files.

I am not wanting to do anything contrary to what you describe here. Being logged in as user “joe” (or “pete” as you call that user) and then starting up a parallel user session and entering “john”'s password at the login screen, user “joe” is becoming user “john” and then it is user “john” editing his own files. I am asking to do nothing different as far as that system security is concerned. Logged in as user “joe” I still would enter “john”'s password, become user “john” and then it would be user “john” editing his own files. I am simply asking for a more streamlined way of doing this. Specifically what I am asking for is this: instead of having to do all of the following: go to the start menu; go to “leave”; go to “switch user”; click on the button at the top of the desktop that says “start new session”; get the system login screen; enter “john”'s password; have “john”'s desktop appear in place of “joe”'s desktop and have to use <CTRL><ALT><Fn> to switch back and forth; simply to become user “john” so that user “john” can edit his own files; I want to click on an icon on “joe”'s desktop, pull up a small window where I enter “john”'s password and then pull up a dolphin file manager window on “joe”'s desktop that the system has set up to run under user “john” and then it is user “john” editing his own files. Since I enter “john”'s password in both cases, the system security remains intact.

Previously, all that was needed to get this done was a simple KDESU (or su -l …) sequence where I would enter “john”'s password followed by a call to the file manager program. Now, a lot more needs to be done, including creating a fully populated directory of /run/user/<“john” numeric user ID>. Even “kdesu dbus-launch dolphin” after having entered “john”'s password and having changed to “john”'s environment is not enough.

Could you please tell me everything that needs to be done to properly set up whatever is needed, including creating a fully populated directory of /run/user/<“john” numeric user ID>, so that I (user “joe”) can start up dolphin running as user “john” but sitting as a window on “joe”'s desktop, simply by calling up a KDESU windows and entering “john”'s password. In other words, could you please tell me what programs, shell scripts, etc. are run to bring up “john”'s desktop when I (user “joe”): go to the start menu; go to “leave”; go to “switch user”; click on the button at the top of the desktop that says “start new session”; get the system login screen and enter “john”'s password.

kdesu should work using the -u option to change users

Yes, but you cannot start dolphin that way (well, you can, but it doesn’t really work…).

Otherwise this thread wouldn’t even exist I suppose.

Don’t know then If I want to mess with a different user I just become root. Maybe the environment does not change like su without dash. That would mess things up a bit.

No, that’s not the reason either.
Dolphin doesn’t work after running “su - username” too.

Btw, the reason does have to do with permissions:

Error: cannot create directory "/run/user/1000": Permission deniedtrying to create local folder /run/user/1000: Permission denied
kdeinit4: Aborting. bind() failed: No such file or directory
Could not bind to socket '/run/user/1000/ksocket-test/kdeinit4__0'

As I said, the only thing I can suggest is to use a different (simpler) file manager.
GNOME’s nautilus does seem to work btw, although it spits out similar error messages:

(nautilus:8247): dconf-CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

Let’s try a different approach. Please tell me the exact shell script, or program with its complete set of options and arguments, that is run when I click on the menu option as shown in the screenshot below:

http://www.techccu.com/users/compwiz/pictures/opensuse-forums/thread1/snapshot4.png

If using kdm, you can do the same via:

kdmctl reserve
kdmctl reserve

gets me to the kde login screen where I enter john’s password and then get to john’s desktop. Now, how do I automatically make the system switch back to joe’s desktop after john’s desktop has been brought up? Alternatively, how do I get kdmctl to use the global socket (running kdmctl as root is no problem)?

Logout.

Or press Ctrl+Alt+F7. Ctrl+Alt+F8 should get you back to the second session again.
IOW, you can switch between the two currently running user sessions with Ctrl+Alt+Fx (with x being 7 or 8).

Alternatively, how do I get kdmctl to use the global socket (running kdmctl as root is no problem)?

kdmctl does use the “global socket” of the running kdm.
You should be able to use it as user too, no need to run that as root.

Those require intervention by the user whereas I want a fully automatic approach. However, there is a worse problem, namely: after john’s KDE session is started and joe then logs in as john and runs dolphin as john in joe’s KDE session, if john’s KDE session is then shutdown and restarted, then both joe’s and john’s KDE sessions will collide. The only way to prevent that is for joe to logout of his KDE session and log back in.

Therefore, I have another question: how can I cause a KDE session to be automatically restarted? In other words, have a shell script execute “kdmctl suicide” (which will end joe’s current KDE session) and then have that same shell script automatically start a new KDE session for joe (without me having to manually login again as joe).

Alternatively, if I open up dolphin in system user mode from within joe’s KDE session, is it possible to tell that dolphin file manager to automatically write out everything using john’s file permissions instead of root’s?

Yes. You started a standard new user session.

But that’s what you asked.
How to create a new session via some command.

Apparently what you asked is not what you want though.

However, there is a worse problem, namely: after john’s KDE session is started and joe then logs in as john and runs dolphin as john in joe’s KDE session, if john’s KDE session is then shutdown and restarted, then both joe’s and john’s KDE sessions will collide. The only way to prevent that is for joe to logout of his KDE session and log back in.

No, they don’t collide.
Why do you think that?

And I think you misunderstood something.
If you run “kdmctl reserve”, you create a completely independent user session.
I.e. user john logs in, it’s not user joe that logs in as user john.

Linux is a multi-user system, it is perfectly possible to have several (even hundreds) of users logged in at the same time.

And again, you can switch between those sessions with Ctrl+Alt+Fx, no need to logout.

Therefore, I have another question: how can I cause a KDE session to be automatically restarted? In other words, have a shell script execute “kdmctl suicide” (which will end joe’s current KDE session) and then have that same shell script automatically start a new KDE session for joe (without me having to manually login again as joe).

You can’t.

It is possible to “remote control” KDE via DBUS to some degree (e.g. it is possible to automatically logout).
But if a user logs out, he is logged out and has to login again.

So what you actually still want to do is just run a file manager as a different user?
Then this approach is thinking way too complicated anyway.

Alternatively, if I open up dolphin in system user mode from within joe’s KDE session, is it possible to tell that dolphin file manager to automatically write out everything using john’s file permissions instead of root’s?

No.
If it is running as root, it is running as root.
But if you copy/move files, they will keep their original permissions, it’s not that dolphin writes out anything.

As I already said, I don’t see a way to do what you want with dolphin, mainly because dolphin relies on certain KDE services to be running.
It should be possible with a simpler file manager though, like mc, or even nautilus.

PS: I just noticed that it actually does work to run dolphin as different user in the current session, if you create the corresponding directory /run/user/XXX manually.

I.e. if you are logged in as user joe with user id 1000, and want to run dolphin as user john with userid 1001, create the directory /run/user/1001/ and make user john the owner.
You can do that with dolphin as root e.g., or via something like this:

sudo mkdir /run/user/1001
sudo chown john: /run/user/1001

Afterwards you can run dolphin as user john by using “su - john”, or with:

kdesu -u john dolphin

This /run/user/XXX directory is normally created by systemd/logind when the user logs in.

It might be possible to configure PAM so that it gets created automatically when switching to a different user with su, but I can’t tell you how at the moment.

And so it does, as is the most streamlined way yet to do what I originally wanted, which is to have a limited session of “john” opened in “joe’s” desktop session, so that I don’t have to clumsily switch between 2 separate desktop sessions to move data back and forth between “joe” and “john”. I suspect that you will also find that your “simple” file managers like nautilus will also work properly as well, whereas before you found out that they gave you the same errors that dolphin did. Unfortunately, both joe’s and john’s desktop sessions will still collide if a full desktop session for “john” is started while the desktop session for “joe” remains active. By collide, I mean: the login screen for “john” comes up properly; I login as “john” and instead of “john’s” desktop on vt8 I get a black screen; “john’s” desktop screen comes up instead on vt7 and that is also where “john’s” keyboard input is received as well, but a limited number of system messages such as the logout confirmation will show up on vt8; “john’s” and “joe’s” open programs all get mixed up on vt7. The only way to prevent this collision is to log “joe” out and back in again after having run dolphin under user “john” in “joe’s” desktop session. The problem appears to be with the “kdeinit4_1” socket(s) in /run/user/<joe’s UID>/ksocket-joe. That is why I had asked if they was a way to automatically log “joe” out and back in again. Alternatively, if those “kdeinit4_1” socket(s) for “joe” can be “refreshed” without needing to log “joe” out and in again, that is even better.

This is not a problem. A shell script running under root can do all the necessary setup and cleanup.

I originally wanted, which is to have a limited session of “john” opened in “joe’s” desktop session, so that I don’t have to clumsily switch between 2 separate desktop sessions to move data back and forth between “joe” and "john.

If that is the reason for the exercise then seems to me using group permissions is a better way