Few days back I mistakenly formatted a partition on my external hard drive by clicking Format from the Context menu in Computer. I want to know that how can I prevent non-root user from being able to do so. At the same time I need the non-root user to be able to read and write on the partition.

I use Fedora 14.


3 Answers 3


As nc3b already pointed out, this gets controlled by PolicyKit. The policy for disks is located at: /usr/share/polkit-1/actions/org.freedesktop.udisks.policy and can be adjusted.
Open it with root rights and search for the line: <action id="org.freedesktop.udisks.change">, either comment out the whole block: <!-- [udisks.change-block] -->, or set <allow_active> to 'no', save and exit.

Check if it's disabled:

$ pkaction --verbose --action-id org.freedesktop.udisks.change
No action with action id org.freedesktop.udisks.change

Or if you've set no:

implicit active:   no

Good, next time you try to format a device as a non-root user, either over the context menu or over 'Disk Utility', an error message will appear an disallow it. This step will still allow the non-root user to read/write the device.

If you still want to allow formating of devices, but with a higher security level, you can force PolicyKit to ask for a password every time.
Open the same file and go to the same section, substitute the 'yes' with 'auth_admin' in allow_active:



$ pkaction --verbose --action-id org.freedesktop.udisks.change
implicit active:   auth_admin


Note: I've only tested this on Ubuntu, but Fedora also uses PolicyKit, so try it with a dummy drive first.

  • Wow!! That's exactly what I wanted. Instead of commenting the the block I did <allow_active>no</allow_active>. Hence I can't format it at all. But then <allow_active>auth_admin</allow_active> seemed a better choice. Thanks a ton..!!
    – Dharmit
    Jan 31, 2011 at 17:10
  • Great answer. But 1 note that, the default actions of policyKit shouldn't be overridden directly in the file, but instead using an override file in /etc/polkit/localauthority with .pkla extension
    – Anwar
    Aug 19, 2016 at 14:27

This is most likely a case of policy elevation. When you do it from an honest terminal this is what happens:

nc3b@aiur:~$ /sbin/mke2fs -jv /dev/sda1
mke2fs 1.41.3 (12-Oct-2008)
mke2fs: Permission denied while trying to determine filesystem size

When you do it from gnome or whatever there's a daemon whose task is to elevate your privileges when you want to perform a superuser action (it usually warns it's a privileged operation and asks for a password). I believe Fedora uses PolicyKit but these systems work similarly.

The real danger of most of them is that they offer to "Keep this password in the keyring" or something like that and don't warn you again.

sudo,[6] gksudo, and kdesu do not ask the user to re-enter their password every time it is called to elevate a program. Rather, the user is asked for their password once at the start. If the user has not used their administrative privileges for a certain period of time (sudo's default is 5 minutes[6]), the user is once again restricted to standard user privileges until they enter their password again.

So the solution is to use a user that simply doesn't have the right to perform these tasks, even if he enters his password.


Fedora has some serious security problems if it allows non-root users to format the disk. Best thing to do is this:

chown root:root /dev/[sh]da[0-9]
chmod 0600 /dev/[sd]da[0-9]

Then, if by needing the "non-root user to be able to read and write on the partition" you mean reading and writing to the file system, then it should be fine provided it is mounted.

If you mean the other thing, then modifying the permissions on the program that is doing the reading and writing (possibly by running it through sudo) might solve the issue.

Other than that, I think the partition structure is stored in the superblock of the disk (e.g. /dev/sda -- no numbers) and thus, setting that to 0600, and the partitions to a more permissive mask (like 0660 and group-owned) might solve the problem.

  • 1
    This won't be persistent, a reboot or simply a udevadm trigger will reset the permissions to default.
    – wag
    Jan 31, 2011 at 12:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .