I just installed openSUSE 12.3 KDE and noticed that I couldn’t mount one of my NTFS partitions without root access. I used KDE Settings->Actions Policy to change the authorizations for org.freedesktop.udisks2.filesystem-mount-system to “yes” for Active console, but I am still prompted for a root password every time. How do I fix the mounting permissions so I do not need root access?
Ben
you should add the mount into your /etc/fstab(something like):
//server_ip/server_share_name /home/your_user/share_name cifs credentials=/home/your_user/.ssh/.creds,_netdev,uid=dan,gid=users 0 0
in this file /home/your_user/.ssh/.creds you have these entries:
username=your_username
password=your_password
this should belong to you /home/your_user/share_name otherwise you’ll not have some rights issues
Hello Benjamin,
I had the same problem and spent some days looking for a solution. I’m not a polkit expert but i think there’s something wrong with it: either it is poorly documented or it is too frequently changed without compatibility in mind or very few people know exactly how it works.
Here is the solution I found (it’s not my own actually, but i googled really hard to find it):
// Password-less mounting of local partitions
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.filesystem-mount-system" &&
subject.active &&
subject.user == "your_standard_username") {
return polkit.Result.YES;
}
});
This will let standard_user mount system partitions on active console.
You can find on the Net the proper code to do the same thing with a group instead of a user.
A few remarks:
I agree that the documentation is lacking and dated. The ‘pkaction’ command can be used to list/view policies.
To get a list of active policies
pkaction
To get the current privilege settings for udisks2.filesystem-mount-system, type
pkaction --action-id org.freedesktop.udisks2.filesystem-mount-system --verbose
The openSUSE_121 polkit guide explains
In order to define your custom set of privileges, use /etc/polkit-default-privs.local. Privileges defined here will always take precedence over the ones defined in the other configuration files.
For example, in /etc/polkit-default-privs.local, one could add the following custom privilege
org.freedesktop.udisks2.filesystem-mount-system auth_admin:auth_admin:yes
To make it take effect, you then run (as root)
set_polkit_default_privs
This will write the changes to /var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.udisks2.filesystem-mount-system.pkla
This refers to system devices. For removables action is supposed to be org.freedesktop.udisks2.filesystem-mount (without system) and at least here it correctly allows active session.
bor@opensuse:~> pkaction --action-id org.freedesktop.udisks2.filesystem-mount --verbose
org.freedesktop.udisks2.filesystem-mount:
description: Mount a filesystem
message: Authentication is required to mount the filesystem
vendor: The udisks Project
vendor_url: http://udisks.freedesktop.org/
icon: drive-removable-media
implicit any: auth_admin
implicit inactive: auth_admin
implicit active: yes
I have seen cases when there was no active session at all; whether current session is considered active can be verified using
bor@opensuse:~> loginctl --no-pager show-session -p Active $XDG_SESSION_ID
Active=yes
My post was simply to illustrate how policies can be adjusted via , hence I used the same policy that patrus referred to.
For reference, I have
# pkaction --action-id org.freedesktop.udisks2.filesystem-mount --verbose
org.freedesktop.udisks2.filesystem-mount:
description: Mount a filesystem
message: Authentication is required to mount the filesystem
vendor: The udisks Project
vendor_url: http://udisks.freedesktop.org/
icon: drive-removable-media
implicit any: auth_admin
implicit inactive: auth_admin
implicit active: yes
# pkaction --action-id org.freedesktop.udisks2.filesystem-mount-system --verbose
org.freedesktop.udisks2.filesystem-mount-system:
description: Mount a filesystem on a system device
message: Authentication is required to mount the filesystem
vendor: The udisks Project
vendor_url: http://udisks.freedesktop.org/
icon: drive-removable-media
implicit any: auth_admin
implicit inactive: auth_admin
implicit active: auth_admin_keep
To see active sessions
ck-list-sessions
This may be useful to others:
No. Console Kit is obsolete and should not be used anymore.
bor@opensuse:~> ck-list-sessions
Session1:
unix-user = '501'
seat = 'Seat2'
active = FALSE
is-local = FALSE
bor@opensuse:~> loginctl --no-pager show-session $XDG_SESSION_ID
Id=2
Timestamp=Sat, 2013-03-23 13:18:47 MSK
TimestampMonotonic=87344100
Remote=no
Active=yes
State=active
bor@opensuse:~>
bor@opensuse:~> loginctl --no-pager list-seats
SEAT
seat0
1 seats listed.
I do not even have seat2 and CK believes session is remote and inactive. Which may actually explain some problems if CK is continued to be used.
I do see ConsoleKit has been replaced with systemd-logind (I’m still using 12.2, so don’t have the latter). Anyway, this discussion concerns polkit privileges…
BTW, you mentioned removable devices (and hence org.freedesktop.udisks2.filesystem-mount) , but the OP was referring to ‘internal’ NTFS partitions. (As dmera pointed out this can be done via the traditional /etc/fstab approach, but udisks2/DE can also handle these as well).
This is a very polite way to picture this issue.
I have been searching the web low and high for days now to find out what’s up with PolicyKit and this posting finally pushed me in the right direction - thanks for this. The documentation at freedesktop.org is misleading, to say the least, because it doesn’t clearly state what the state of the art is. At the suse.org websites there is nothing about the current implementation of PolicyKit.
My use case: I’m using OpenSuse 12.3 and I have a eSATA disk in an external casing sitting on the desktop (the real one) used for archiving stuff. From the user’s point of view this disk should be handled like a USB drive; you just switch it on and off when you need it. No problem with a real USB drive, Opensuse mounts the disk automagically. But not with this drive: from the OS’s point of view it isn’t a removable drive; it doesn’t matter it is in an external casing, it is a system disk and needs manual mounting with root password.
A fstab entry doesn’t help with that; it’s the PolicyKit stubbornly asking for root password. There are “solutions” all over the place on the net, but most of them don’t work because either they are targeted at the real old PolicyKit version or they are focusing on the current PolicyKit version, but don’t work as well.
Actually the solution is pretty easy once you know it. First the things to forget about:
The only place with some substantial documentation is the “latest” compartment containing the polkit Reference Manual at freedesktop.org. But before going there you should have read this blog article by the maintainer of PolicyKit written in June 2012 (one year ago, that is) where he explains why he has changed the whole configuration business of PolicyKit radically. Using such beasts as simple text files like the .pkla files must have been too easy so he changed it all to JavaScript. Needless to say that the whole file system layout of the configuration has changed since. Now it all is in .rules files here and there.
Anyway, that alone would have been too easy. Suse has added one layer on top of it: Instead of editing these Javascript .rules files you are meant to edit one config file (a simple text file, for a change) and then let a custom program read this source config file and write your custom config to such a Javascript file. And here we go:
Opensuse provides three text config files:
/etc/polkit-default-privs.local
/etc/polkit-default-privs.standard
/etc/polkit-default-privs.restrictive
The names of the latter two speak for themselves; they are meant to serve as prefab config files for either home user or corporate users. In the file /etc/sysconfig/security there is a setting CHECK_POLKIT_PRIVS=“” which of course may be set either to “standard” or “restrictive” (defaulting to “standard”).
/etc/polkit-default-privs.local is the one and only file to be edited which then is meant to override the default config file (standard or restrictive). So far it is just a template. As your first step you can just cut and paste lines from one of the two other config files into the polkit-default-privs.local file; in this case that would be this single line:
org.freedesktop.udisks2.filesystem-mount-system auth_admin:auth_admin:auth_admin_keep
You would just change the final value to “yes” and then you have …
… and finally the second and final step:
And that’s it. The changed configuration gets written to the file /etc/polkit-1/rules.d/90-default-privs.rules which apparently is the decisive one to be used by PolicyKit (see the “latest” documentation).
I’m not sure about that. On my system actually there wasn’t such a file written at all. The only file I have met in that vicinity was one file /var/lib/polkit-1/localauthority/75-polkitkde.d/org.freedesktop.udisks2.filesystem.pkla which obviously had been written during my experiments with the KDE system settings module.
One last note: This simple config (once you know it) will pop up the SuSEplugger when the disk is powered up. I first observed that I had to click at the icon of the drive to actually mount it without being prompted for any password. Later I didn’t need to click at all; it went just automagically without any interaction. Don’t know how that delay at the first time came about; maybe I was too impatient then.
Some corrections/clarifications:
/var/lib/polkit-1/localauthority (and /etc/polkit-1/localauthority) isn’t used anymore as of 12.3. That was only respected in older versions.
The KDE system settings module doesn’t write to /var/lib/polkit-1/localauthority. It writes to /usr/share/polkit-1/actions/ instead. There packages like udisks2 bring their default actions, so this gets overwritten on package updates (and is overridden by the settings in /etc/polkit-1/rules.d/ anyway). That’s why the system settings module is not installed anymore by default (but it still was in 12.3 GM). See kdebase4-workspace’s changelog:
- Sat May 18 2013 hrvoje.senjan@gmail.com
- Remove polkit-kde-kcmmodules-1 from Requires, as the package is
broken - it overwrites rules shipped by other packages (kde#308934),
and confuses users that it does something it doesn’t (bnc#814763)
Thanks for clarifying the changes. It’s a fast moving platform…
This old chestnut AGAIN. Just upgraded to 12.3 and now found it is even more difficult to mount INTERNAL drives on a LOCAL SYSTEM.
I’m with Linus Torvalds:
“Whoever moron thought that it’s “good security” to require the root password for everyday things like this is mentally diseased”
>:(
A quick note about the mention of java script. The change has probably been made so that Kwin can be used. A search for that will bring up sources of the version of java script that is actually used for KDE scripting and documentation. Initial indications are that this doesn’t offer the ability to make use of bash scripts etc as per KDE of old. On the other hand it might but there aren’t any doc’s I can find.
On adding discs I would hope that YAST partitioning can still cope with that - leaving the only root can write to the root of the disc so a user partition has to be created. Same with discs in a USB dock. Maybe Linus Torvalds was thinking of windoze. Not used it for a long time but it used to be plug it in and reboot. More than one user on a single machine probably complicates that now but maybe anyone can use it.
Sorry, but what are you talking about?
This has absolutely NOTHING to do with Kwin.
Udisks2 uses polkit to determine if the user f.e. is allowed to mount a disk or not (or if a password should be asked).
And I don’t get what you mean with “this doesn’t offer the ability to make use of bash scripts etc as per KDE of old”, but that’s COMPLETELY OFF-TOPIC here anyway.
Udisks2 doesn’t have anything to do with KDE, it’s just that KDE (and GNOME) uses it to mount disks.
On adding discs I would hope that YAST partitioning can still cope with that - leaving the only root can write to the root of the disc so a user partition has to be created. Same with discs in a USB dock.
Yes, you still can use YaST for that, or just edit /etc/fstab manually.
But you also need root permissions for that…
Of course if the disk has a Linux filesystem, Linux user permissions apply. So if the files/directories on it are owned by root (or a different user), the user may not be able to write to it (or even read) although he is allowed to mount the disk.
The comment on the fact that some software was now using js rather than staying as it was. Also a source of a js reference manual. Kwin? Depending on where you look it can be scripted with JS. The interpreter is already there.
True on bash scripts etc from kde. Off topic but on my mind at the moment and the answer may be WMIface but not JS.
Right, javascript and interpreters for it existed long before KDE4 and polkit. So what?
You could already write scripts in javascript, python and ruby in KDE3 times (Amarok and KOffice f.e. were already scriptable). Only KWin wasn’t scriptable yet back then, that got added recently (4.9 or 4.10, not sure right now).
But what’s that got to do with mounting disks? Or with the fact that polkit now uses some kind of javascript for its configuration?