Pulse permissions after upgrade to 13.2

English Install/Boot/Login
21

Searching Yast for “gnomesu” or “kdesu”, or even “xdg-su” showed nothing, there’s “kdesu-devel” and also a couple of libgnomesu packages. I’ve never installed Gnome or Kde here, only Xfce.

stan@linux-ektu:~> xdg-su -c /sbin/yast2 --qt
xdg-su: unexpected option '--qt'
Try 'xdg-su --help' for more information.
stan@linux-ektu:~>

There’s a newer bug #908167 with the same problem but it’s filed for 13.2 RC1 and last message there was a month ago. It’s still marked In_Progress so I’m not sure what to do.

22

gnomesu is inside the package libgnomesu, kdesu is in kdebase4-runtime, and xdg-su in xdg-tools which you definitely have installed.

I’ve never installed Gnome or Kde here, only Xfce.

Still, in XFCE xdg-su uses gnomesu by default and falls back to “su -” if that is not installed.
Testing with gnomesu directly should show whether the problem lies in xdg-su or in gnomesu. I don’t think kdesu has this problem, as I never saw it here.

stan@linux-ektu:~> xdg-su -c /sbin/yast2 --qt
xdg-su: unexpected option '--qt'
Try 'xdg-su --help' for more information.
stan@linux-ektu:~>

Sorry, you need quotes in this case:

xdg-su -c "/sbin/yast2 --qt"

There’s a newer bug #908167 with the same problem but it’s filed for 13.2 RC1 and last message there was a month ago. It’s still marked In_Progress so I’m not sure what to do.

Ok, so no need to reopen the other one or file a new one.

It is in state NEEDINFO, i.e. the assigned maintainer of xdg-su waits for additional information from the GNOME maintainers regarding the inner workings of gnomesu. Not much you can do here at the moment I suppose. But maybe your comment will attract their attention…

According to this bug report the problem seems to be in gnomesu. So try to uninstall libgnomesu (if possible), xdg-su should fall back to “su -” then and the problem should not occur.
Another workaround should be to apply the patch in comment#5. /usr/bin/xdg-su is just a shell script (i.e. text file), so open it in a text editor (you have to do that as root) and add those lines that are beginning with a ‘+’ (without the ‘+’).

23

Oops. xdg-su is in xdg-utils of course… :wink:

24

On 2015-01-19 13:56, wolfi323 wrote:
> Stan_Ice;2690004 Wrote:

>> By “keyring” I meant “Login” entry that appears under Passwords in
>> “Passwords and Keys” program in XFCE Accessories. It can have a separate
>> password from my login and to open it automatically I set this keyring’s
>> password to blank. I’ve dealt with it a long time ago and so not sure
>> how exactly it’s supposed to work but that was the solution I found then
>> and it still works now, except a few days after the upgrade it started
>> reporting that it’s unlocked and I had to set password to blank again.
> This is indeed gnome-keyring then I suppose.

Seahorse?

> As I wrote, when using gdm, lxdm, or lightdm, the keyring should be
> automatically unlocked at login via pam. For this to work it must have
> your user’s password I think.

I see a padlock icon on the “login” entry, and it is unlocked. It
contain entries made by Chrome, even banks! But the password field is empty.

It also stores passwords to encrypted PDFs. These are really stored, and
I can click to display and show, without prompting me to type a
password. A visitor could just click and see them.

On Firefox password manager, for instance, it asks for the master
password before displaying the stored passwords.

This thing is not secure.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

25

On 2015-01-19 13:56, wolfi323 wrote:
>
> robin_listas;2689575 Wrote:
>> On 2015-01-16 16:36, gogalthorp wrote:
>>>
>>> DO you ever log in as root to a GUI? If so stop it.
>>
>> He said not.
>>
> And even if he did, that wouldn’t automatically touch any user
> files/directories.

True.

> It is actually more dangerous to run programs as root in your user’s X
> session than logging in as root regarding this.
> If the environment is setup wrong, they might end up accessing user’s
> files/directories like /run/user/xxx/ or config files in the user’s home
> and even change the ownership.

Oh, yes, true.

Which is why I don’t use sudo, but “su -”.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

26

On 2015-01-20 09:26, wolfi323 wrote:
>
> Stan_Ice;2690189 Wrote:
>> I “figured” it out - on Xfce Yast uses GTK, takes over pulse directory
>> as root and then never releases it.
>>
>> Just checked, changed ownership back to myself, started Yast, and sure
>> enough, it took over /run/user/1000/pulse and never let it go. Works the
>> same for either Software Management or the main Yast panel.

Curious!

> Well, sounds exactly like this bug report:
> https://bugzilla.opensuse.org/show_bug.cgi?id=852015
>
> But that should have been fixed via an online update in 13.1.

At least in 13.1 XFCE it does not happen, in my system.

It is using this sequence of tools (trimmed ps afx):

cer 13:52 0:00 /bin/sh /usr/bin/xdg-su -c /sbin/yast2
cer 13:52 0:00 _ /usr/bin/gnomesu -c /sbin/yast2
root 13:52 0:00 _ /usr/lib/libgnomesu/gnomesu-pam-backend 12 11 root /sbin/yast2
root 13:53 0:00 _ /bin/bash /sbin/yast2
root 13:53 0:01 _ /usr/lib/YaST2/bin/y2controlcenter-gnome

And the ownership of pulse did not change.

Comment #6 says that the solution is temporary, waiting for a final one on systemd.

(what they did at this time was modify “pulse” instead of xdg-su)

Comment #17 mentions a modification to systemd, backported to version 208, that works partially.
It was improved later on.

Finally an update was released around 2013-12-09.

> Does this also happen when you run the Qt version if YaST? The GTK
> interface has been dropped recently because it has no maintainer, and
> there were some (severe) problems that nobody worked on.

What? :open_mouth:
I’m surprised.

Does this mean the entire Yast GTK “flavour”, or just the sw-single, sw-online modules?
These two are very different in GTK: not only looks, but actual functionality and behaviour.
The rest of the modules only have different look than the QT modules, matching gnome environment.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

27

The whole GTK interface has been dropped, i.e. the packages libyui-gtk and libyui-gtk-pkg (the latter contains the software management interface).

It is still included in 13.2 but not installed by default (even on a GNOME installation), and has been completely removed from Factory 3 months ago:

https://bugzilla.opensuse.org/show_bug.cgi?id=907717#c13

28

Ok, pulse gets taken over by root when starting Yast in both xdg-su and gnomesu, but not kdesu. Starting yast with --qt , however, leaves pulse owned by me in either gnome- or xdg-su. I think I can edit my menus to include --qt as a workaround while the problem gets fixed by developers.

Robin, there’s a newer discussion of this bug #908167 as it appeared in 13.2 RC1. I’ve never seen this problem on 13.1 either, it appeared after upgrade to 13.2.

The keyring, and yes, I think it’s managed by Seahorse even though it’s not what it’s called in the menu, so the keyring didn’t get unlocked again. There were some updates that might have changed its behavior or it could be related to something else.

Reading up on it, setting password to blank is just a workaround, it SHOULD get unlocked on login but somehow it doesn’ t happen. It’s the only keyring I have, ie not “Default” and “Login”, only “Login”, and it stores only Chrome passwords. Chrome starts on login and it’s probably Chrome that shows “keyring unlocked” popup.

29

Hm, then it’s probably a bug in YaST Gtk, maybe even triggered by the combination of gnomesu and YaST Gtk.
Running “su -” followed by “yast2” (or “yast --gtk” to be sure the Gtk version is started) will not cause the problem I suppose? Or does it?

This information should probably be added to the bug report.

Another workaround would be to uninstall YaST Gtk, i.e. the packages libyui-gtk6 and yast2-control-center-gnome.
Or you can set which GUI to use in /etc/sysconfig/yast2.
No need to change the menu entries…

30

Running “su -” followed by “yast2” (or “yast --gtk” to be sure the Gtk version is started) will not cause the problem I suppose? Or does it?

No, it doesn’t.

What’s the difference between “Yast GTK” and “yast --gtk”? Is “YaST Gtk” a separate package from “yast”? What is “yast2” then? Kde version?

I’ve edited menu entries manually already, adding “–qt” to Software Manager and Yast itself in /usr/share/applications/, will tweaking /etc/sysconfig/yast overwrite those edits or get registered elsewhere? Should I change only WANTED_GUI or WANTED_SHELL, too?

31

What’s the permission in your /home/user/.dmrc?

32

On 2015-01-21 14:26, Stan Ice wrote:

> What’s the difference between “Yast GTK” and “yast --gtk”? Is “YaST Gtk”
> a separate package from “yast”? What is “yast2” then? Kde version?

“Yast GTK” is just a name, the command is “yast --gtk”. Yes, there are
separate packages, but you never call them directly.


/usr/lib64/yui/libyui-gtk-pkg.so.5
/usr/lib64/yui/libyui-gtk-pkg.so.5.0.0
/usr/lib64/yui/libyui-gtk.so.5
/usr/lib64/yui/libyui-gtk.so.5.0.0
/usr/lib64/yui/libyui-ncurses-pkg.so.5
/usr/lib64/yui/libyui-ncurses-pkg.so.5.0.0
/usr/lib64/yui/libyui-ncurses.so.5
/usr/lib64/yui/libyui-ncurses.so.5.0.0
/usr/lib64/yui/libyui-qt-graph.so.5
/usr/lib64/yui/libyui-qt-graph.so.5.0.0
/usr/lib64/yui/libyui-qt-pkg.so.5
/usr/lib64/yui/libyui-qt-pkg.so.5.0.0
/usr/lib64/yui/libyui-qt.so.5
/usr/lib64/yui/libyui-qt.so.5.0.0

I think it is them (the listing is from 13.1, your’s will be a bit
different).

Looking at the “/sbin/yast2” script, I see:


GNOME_SHELL="$ybindir/y2controlcenter-gnome"
KDE_SHELL="$ybindir/y2controlcenter"

which reside in /usr/lib/YaST2/bin/

> I’ve edited menu entries manually already, adding “–qt” to Software
> Manager and Yast itself in /usr/share/applications/, will tweaking
> /etc/sysconfig/yast overwrite those edits or get registered elsewhere?
> Should I change only WANTED_GUI or WANTED_SHELL, too?

I think that you should only change those two vars, no need to edit your
menu entries - unless they specify --gtk.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

33

Nothing out of the ordinary:

stan@linux-ektu:~> ls -l .dmrc
-rw-r--r-- 1 stan users 44 Sep 10 20:16 .dmrc
stan@linux-ektu:~>
34

I changed menu entries back to originals and set Yast to use “qt” in /etc/sysconfig instead, neither Yast nor “Install/remove Software” takes root ownership over pulse so it looks like a best workaround for the time being.

Incidentally, setting qt as WANTED_SHELL and WANTED_GUI did not affect the menu at all, I mean their respective .desktop files in /usr/share/applications were not modified by /etc/sysconfig.

35

On 2015-01-22 06:36, Stan Ice wrote:

> Incidentally, setting qt as WANTED_SHELL and WANTED_GUI did not affect
> the menu at all, I mean their respective .desktop files in
> /usr/share/applications were not modified by /etc/sysconfig.

That’s right.

The code in the yast script reads those variables and then decides what
to actually call, each time you call it.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

36

In case you haven’t noticed: an update to libgnomesu has been released today.
So you might want to try with YaST GTK again (and gnomesu/xdg-su), to see if the issue is really fixed. (after installing the update of course… :wink: )

37

Yes, new libgnomesu-1.0.0-353.4.1 is now in the update repo, but I’ll get to that machine only on Monday so will check later.

Thanks for everybody’s help.