LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   SUSE / openSUSE (https://www.linuxquestions.org/questions/suse-opensuse-60/)
-   -   Collision between GUI sessions in openSUSE 13.2 if program from another user run under first user GUI session. (https://www.linuxquestions.org/questions/suse-opensuse-60/collision-between-gui-sessions-in-opensuse-13-2-if-program-from-another-user-run-under-first-user-gui-session-4175584608/)

xode 07-14-2016 04:16 AM

Collision between GUI sessions in openSUSE 13.2 if program from another user run under first user GUI session.
 
1 Attachment(s)
Originally, after finding out that kdesu, followed by dolphin, did not work, I had posted at http://www.linuxquestions.org/questi...er-4175557111/ asking how I could open up a file manager window under a user other than the one the full GUI session belonged to.

For example, if I have the computer booted into a full KDE GUI desktop session under user joe, I had posted on that previous thread asking how I could open up in joe's KDE desktop session a file manager window running under user john and with the privileges of user john (instead of joe).

Ultimately, I got that first question answered, but then encountered another problem. If I have the computer booted into a full KDE GUI desktop session (on vt7) under user joe and open up a file manager window under user john in joe's KDE desktop session, and then open up a full KDE GUI desktop session (on vt8) under user john as shown in the attached screenshot, the two KDE GUI desktop sessions will collide. Specifically, john's desktop screen and keyboard input will show up on vt7 and will hide joe's desktop screen and keyboard input. However, some of john's windows (e.g. the logout confirmation screen) will still show up on vt8 and will only accept input on vt8. This collision will occur even if I close out the file manager window for john in joe's KDE desktop session before opening up a full KDE GUI desktop session under user john. If I already have a full KDE GUI desktop session under user john open before I open up a file manager window under john in joe's KDE desktop session, the collision will occur if I close out john's KDE desktop session and then open another KDE desktop session under john. This collision also occurs with user root. If I open up a file manager window under root using the command as setup by the openSUSE 13.2 install program and then open up a full KDE desktop session under root, the same collision between joe and root will occur. The only way to prevent the collision is to log joe out and then log joe back in again after having closed out the file manager window under john (or root) and before opening up any full KDE GUI desktop sessions under any other users.

Since the following sockets get replaced when joe logs out and then back in again:

Code:

/run/user/<UID joe>/ksocket-joe/kdeinit4__0
/run/user/<UID joe>/ksocket-joe/kdesud_:0

...I would like to know the names of the programs that are responsible for creating and removing those sockets, as well as the names of the RPM files those programs belong to.

My questions are:
  1. has this collision problem already been fixed and is it just a matter of upgrading some RPMs in order to get rid of this collision problem? If that is the case, could you please give me the full filenames for those RPMs so that I can manually upgrade them. The computer on which I have the openSUSE 13.2 installed does not connect to the internet so I will need to download and install those RPMs manually.
  2. if this collision problem hasn't been fixed, is there a workaround available where I can refresh those sockets, and anything else that might also need refreshing, such that I don't have to log joe out and back in again.

xode 10-30-2016 09:45 PM

From the openSUSE mailing list (opensuse@opensuse.org >> SLE <opensuse@opensuse.org>), when I put this question there, I received the following response:

Quote:

su (or kdesu) still leaves you running only one xorg stack owned by Joe, and it maps things
across as best it can, but it's still one xorg, one dbus and (I suspect) one of several other things.

This has never worked well in the same machine since kde3. (At least not under KDE4/5/Plasma).

It will try to make things work (poorly) that would have otherwise have failed outright if you were accessing via ssh from afar. (Or might have worked with no corruption in some cases).

I think some desktop environments handle this more elegantly, but KDE has leakage when you do it this way.
Having received nothing further on how I might be able to manually replicate the xorg stack, the dbus and the several other things, using a shell script, and getting the impression that the GUI collision problem is due to how the GUI infrastructure itself is structured as opposed to a bug that will in time be fixed, I concluded that any solution to this problem would at best be a workaround.

The following is the workaround that I put together:
  • create a new user that is a copy of john called john00
  • create a new group called john containing only users john and john00 and make that group the default group for both users john and john00
  • Setup one specific folder (e.g. workspace) under /home/john that will be used by both users john and john00
  • Set the file permissions for workspace as follows:
    Code:

    setfacl -d -m g::rwx /home/john/workspace
    setfacl -d -m o::rx /home/john/workspace

    ...so that any new files and folders under workspace by default are created to give the group john the same permissions as either user john or user john00

It is not perfect, however. If, from within user joe's full GUI KDE session, a file manager is brought up under john00 and a folder containing other files and folders is copied from joe to john00, only the folders themselves get the proper permissions. All files contained in that folder and its subfolders keep the permissions they had under joe. See http://www.linuxquestions.org/questi...folder-605129/ for details on the setfacl tip that I used here.

xode 02-19-2017 12:09 AM

I have since found an actual solution to this problem as opposed to the workaround I posted previously: install and use the KDE3 desktop on openSUSE 13.2 and the collision between users as described above goes away. It also looks like the KDE3 desktop is available for openSUSE versions later than openSUSE 13.2 as well: https://en.opensuse.org/KDE3

Installation of the KDE3 desktop does not in any manner conflict with what has already been installed. It simply becomes another available session type to choose from when you first log in.


All times are GMT -5. The time now is 08:20 PM.