GNOME != Fedora [LWN.net]

GNOME != Fedora

Posted Nov 5, 2011 13:08 UTC (Sat) by Wol (subscriber, #4433)
In reply to: GNOME != Fedora by BlueLightning
Parent article: Rawhide gets GNOME Shell for all display types

Probably "it doesn't do what I want, and I can't find out how to change it!".

KDE is busted for me, too, in some respects - it's not network transparent! I have an old system I use as a terminal.

Log in over xdm, and I get NO notification window. And mounting comes back "only root can mount this device". WHY? That's important to me because I switch between computers and would like my experience to be identical!

Cheers,
Wol

to post comments

GNOME != Fedora

Posted Nov 6, 2011 0:08 UTC (Sun) by nybble41 (subscriber, #55106) [Link] (4 responses)

The "bug" you describe is by design--local console users are allowed to mount removable devices, remote users are not. This is enforced by PolicyKit, not KDE. It seems like a reasonable default to me, though obviously not suitable for everyone.

Placing the following text in a .pkla file under /etc/polkit-1/localauthority/50-local.d/ should allow you to access removable devices via the udisks service (as used by recent KDE versions, or on the command-line via "udisks --mount $dev") regardless of whether you are a local or remote user:

[udisk Permissions]
Identity=unix-user:$your_username
Action=org.freedesktop.udisks.filesystem-mount;org.freedesktop.udisks.filesystem-check;org.freedesktop.udisks.filesystem-lsof;org.freedesktop.udisks.filesystem-eject;org.freedesktop.udisks.filesystem-detach;org.freedesktop.udisks.filesystem-change;org.freedesktop.udisks.filesystem-luks-unlock;org.freedesktop.udisks.filesystem-inhibit-polling;org.freedesktop.udisks.filesystem-set-spindown
ResultAny=yes

Note that the org.freedesktop.* action IDs are all on one line, with no spaces. Replace "$your_username" with your actual UNIX username. The first line is just a label; feel free to change it.

See also pklocalauthority(8) or <http://hal.freedesktop.org/docs/polkit/pklocalauthority.8...>.

GNOME != Fedora

Posted Nov 6, 2011 3:13 UTC (Sun) by butlerm (subscriber, #13312) [Link] (3 responses)

It looks like someone has been drinking a little too much Java there...

GNOME != Fedora

Posted Nov 6, 2011 6:07 UTC (Sun) by nybble41 (subscriber, #55106) [Link] (2 responses)

Are you referring to the format of the configuration file? The INI format, predates Java, of course, and the reverse-DNS naming convention is standard in many situations where unrelated organizations must provide unique IDs. So far as I am aware there is no Java code in any of these components.

It would have been helpful of the action names were grouped a bit better; you can use glob patterns, but the org.freedesktop.udisks.* actions are a mixture of normal user actions (e.g. "mount removable filesystem") and things which should require administrative privileges (e.g. "manage the LVM subsystem" or "lock encrypted LUKS devices unlocked by other users"). I didn't see any obvious combination of positive glob patterns which would be sure to select just the normal user actions, short of listing them all. Renaming the actions enabled by default for interactive sessions to something like org.freedesktop.udisks.safe.* would have allowed for a much more compact configuration, but I realize that has its own issues. Groups, or multiple Action= lines, would be nice. Perhaps the ability to filter actions based on a glob pattern plus the current Result* settings ("allow all udisk actions which this user could use in an active session"). Or at least some (documented) way to break values over multiple lines.

There used to be a GUI for configuring PolicyKit permissions, but apparently no one's updated it for the PolKit-1 redesign.

GNOME != Fedora

Posted Nov 6, 2011 16:32 UTC (Sun) by ABCD (subscriber, #53650) [Link] (1 responses)

There is a GUI for KDE at least, called "polkit-kde-kcmodules-1" upstream (but it hasn't actually been released yet). In Gentoo, we package a snapshot of this repo dated 2010-11-27. This GUI integrates itself with the rest of KDE System Settings.

GNOME != Fedora

Posted Nov 7, 2011 20:26 UTC (Mon) by Wol (subscriber, #4433) [Link]

Thanks all of you for the info.

And I run gentoo :-)

iirc it used to work the way I want, until a recent KDE update dragged in polkit, consolekit, etc etc. Then I started swearing ... :-) part of the trouble is I haven't got the knack of finding the docu - whether I can't think of the right keywords for Google or not I don't know.

Cheers,
Wol

GNOME != Fedora

Posted Nov 6, 2011 8:08 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Nope, just a simple bug - buttons with window names become squashed as if the taskbar is overflowing.

Additionally, windows are added to the _right_ side of the taskbar, not to the left (and no, I don't have Arabic or Hebrew locale set).

I've reported it, but no result so far.

GNOME != Fedora

Posted Nov 6, 2011 23:38 UTC (Sun) by raven667 (subscriber, #5198) [Link] (2 responses)

There is a good reason that doesn't work. Device Notifications are only sent to the user on the local console attached to the machine, not to remote users. There is no way to reliably and consistently handle notifications or access to devices in the remote user case, what would the system do when there are multiple remote users? Even if there is only one user logged in remotely, the first of N remote users shouldn't behave differently, that would be very weird in a multiuser environment

GNOME != Fedora

Posted Nov 6, 2011 23:59 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

what do you do if there are multiple remote users? you notify them all of course.

sending notifications to all users, local or remote is something that has been done for decades on unix systems.

GNOME != Fedora

Posted Nov 7, 2011 16:22 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Many if not most of the hardware access that is appropriate for a local console user, to network, audio, and storage devices is not appropriate for remote users. The OP was asking why they couldn't change local device settings when logged in remotely. There are certainly cases where we want to send a notice to all logged in users but for many of the desktop notifications related to local hardware you probably don't want to broadcast them to all users and you probably don't want all users to have automatically privileged read/write access when plugging in a removable drive for example. It's a much simpler default policy to just draw a line between local console users and remote.