Bug 814626

I too see this issue.Whenever i open gedit as a root user and click on hot sport or click on left windows key(launches activities menu by default) the whole desktop freezes except for the mouse which does remain active which is pretty wierd.

The issue is rather 'simple' to explain what is going wrong:

- User logs in; XDG_RUNTIME_DIR is set to /run/user/$UID/
- dconf-service starts, and 'touches' its lock rile as $XDG_RUNTIME_DIR/dconf/user
- User changes to superuser with 'su'
=> XDG_RUNTIME_DIR is NOT being reset, still points to the USERS one
- gedit is being started
=> it requires dconf access, hence launches a dconf-service on the dbus;
- root's dconf-service overwrites the users lock file, with 'specific' permission
  ==> BAM

@Philip (as maintainer of coreutils / su)

looking at above: do you think 'su' should reset XDG_RUNTIME_DIR ?

In this context I'd say it should do so if XDG_RUNTIME_DIR is set in the callers environment and it shouldn't start a login shell, i.e. isn't called with '-'.

(In reply to comment #4)
> In this context I'd say it should do so if XDG_RUNTIME_DIR is set in the
> callers environment and it shouldn't start a login shell, i.e. isn't called
> with '-'.

in my tests it did not matter much how ended up with 'root' privileges: su, gnomesu, xdg-su, "su -";  => they all resolved in the same issue.

Assigning to pth, as coreutils maintainer.

@carl: as a work around you can do:

su
unset XDG_RUNTIME_DIR
gedit

=> this should give you a working gedit instance with root privileges without the crashes.

*** Bug 819891 has been marked as a duplicate of this bug. ***

(In reply to comment #6)
@dominique
> su
> unset XDG_RUNTIME_DIR

This does not work for me - no difference at all.

> in my tests it did not matter much how ended up with 'root' privileges: su,
> gnomesu, xdg-su, "su -";  => they all resolved in the same issue.

That's what I see here as well. I am starting thunar and there are minor differences: su will allow a few click to navigate through directories, gnomesu and others open the root version of the window in frozen state.

Please let me know if this bug will be solved in near future. I feel some  instability in the system, such as I can't install Cadsoft's eagle. My feeling is that some files/dirs can't be accessed.

Additional info ( just in case ): openSuse 12.3 / 64, Intel, btrfs

As su is in util-linux now I'll let its maintainer voice his opinion.

Disregard the eagle installation, it was a different problem which is solved now.

Waiting for Philipps opinion...

@Andreas: su is in util-linux so its maintainer should chime in. But I'd say that su should reset XDG_RUNTIME_DIR given.

I can confirm, that su in util-linux has a different behavior. It even looks broken to me.

@Philipp

As I said XDG_RUNTIME_DIR reset does not work for me.

Is there any schedule set up for working on this problem?

Frederic, as youre much better versed in GNOME stuff, do you have an idea how to solve this issue?

@Frederic

Do you know if anybody is working on this bug? 

This still is an open issue on my installation and a nasty one because it forces me to work as root more frequently then I should...

(In reply to comment #14)
> Frederic, as youre much better versed in GNOME stuff, do you have an idea how
> to solve this issue?

I think DimStar suggestion should be followed and some specific variable (XDG_RUNTIME_DIR) should be cleared when changing user.

Just looking into su in util-linux. The code is different. su in coreutils did not support pam, and pam support was added as a patch. util-linux su supports pam out of the box. But maybe the old and new su are incompatible, and util-linux does not deliberately provide PAM configuration (see util-linux-2.23.2/Documentation/PAM-configuration.txt).

sbrabec@oct:~> su
su: Authentication failure
sbrabec@oct:~> su -
su: Authentication failure
sbrabec@oct:~>

Ad comment 17: Well, first problem localized: There is a known problem while upgrading symlink to file or directory by rpm. Exactly this happens if somebody installs Factory as upgrade:

/etc/pam.d/su-l remains to be a link to /etc/pam.d/su-l.core (which does not exist), and the new file is installed as /etc/pam.d/su-l.rpmnew

/etc/pam.d/su remains to be a link to /etc/pam.d/su.core (which does not exist), and the new file is installed as /etc/pam.d/su.rpmnew

Manual fixing of this issue:
if test -L /etc/pam.d/su ; then
  rm /etc/pam.d/su
  if test -f /etc/pam.d/su.rpmnew ; then
    mv /etc/pam.d/su.rpmnew /etc/pam.d/su
  else
    echo "Error: /etc/pam.d/su is a link, but /etc/pam.d/su.rpmnew does not exist."
    exit 1
  fi
fi
if test -L /etc/pam.d/su-l ; then
  rm /etc/pam.d/su-l
  if test -f /etc/pam.d/su-l.rpmnew ; then
    mv /etc/pam.d/su-l.rpmnew /etc/pam.d/su-l
  else
    echo "Error: /etc/pam.d/su-l is a link, but /etc/pam.d/su-l.rpmnew does not exist."
    exit 1
  fi
fi

gnomesu starts to work after this fix, but it still does not work properly: There is about 20 seconds delay between entering password and application start.

Note: I'll look into an old version, whether it makes sense to keep su.core and su-l.core.

The delay seems to be a fault of root's atk service.

First invocation of gnomesu (delayed):

sbrabec@oct:~> gnomesu gedit

** (gedit:18490): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.


Second invocation of gnomesu (no delay):

sbrabec@oct:~> gnomesu gedit

** (gedit:20126): WARNING **: AT-SPI: Could not obtain desktop path or name


** (gedit:20126): WARNING **: atk-bridge: get_device_events_reply: unknown signature

** (gedit:20126): WARNING **: atk-bridge: get_device_events_reply: unknown signature

** (gedit:20126): WARNING **: atk-bridge: GetRegisteredEvents returned message with unknown signature

** (gedit:20126): WARNING **: AT-SPI: Could not obtain desktop path or name


** (gedit:20126): WARNING **: AT-SPI: Could not obtain desktop path or name


** (gedit:20126): WARNING **: AT-SPI: Could not obtain desktop path or name


** (gedit:20126): WARNING **: AT-SPI: Could not obtain desktop path or name

Regarding XDG_RUNTIME_DIR:

There is no special code in su for keeping this variable.

su itself can only change these variables: TERM, HOME, SHELL, USER, LOGNAME and PATH, and su -l should drop all other.

But there is another code, that can cause this problem: su (su -l) uses PAM /etc/pam.d/su-l. It contains following line:

session  include        common-session

Looking at /etc/pam.d/common-session-pc, I see:

session	optional	pam_systemd.so

And its /lib64/security/pam_systemd.so matches XDG_RUNTIME_DIR.

Looking at pam_systemd source code, there is really a code, that handles XDG_RUNTIME_DIR specially: pam_sm_open_session()

There is probably a problem with sequence, as it sets XDG_RUNTIME_DIR for incorrect UID (UID before su instead of UID after su).

*** Bug 842746 has been marked as a duplicate of this bug. ***

According to upstream (https://bugzilla.redhat.com/show_bug.cgi?id=753882 ) it can't be fixed..

This is an autogenerated message for OBS integration:
This bug (814626) was mentioned in
https://build.opensuse.org/request/show/202588 Factory / util-linux

On factory I've seen a fix being checked in for a bug that hints to be exactly the same:

bug 852015 (PA socket re-owned by root)

*** Bug 909843 has been marked as a duplicate of this bug. ***

(In reply to Dominique Leuenberger from comment #24)
> On factory I've seen a fix being checked in for a bug that hints to be
> exactly the same:
> 
> bug 852015 (PA socket re-owned by root)

Yes, this is fixed since 13.1.

*** This bug has been marked as a duplicate of bug 852015 ***