search

storaged-project / udisks

The UDisks project provides a daemon, tools and libraries to access and manipulate disks, storage devices and technologies.
https://storaged.org/doc/udisks2-api/latest/
Other
342 stars 143 forks source link

Some default udev rules don't allow the user to mount fat32/ms-dos partitions #610

Open birdie-github opened 5 years ago

birdie-github commented 5 years ago

I've discovered that as a user I'm unable to mount the system UEFI partition on my USB flash drive which is very weird because I need to work with it.

Can we please remove some of the following rules from 80-udisks2.rules, e.g. the ones which prevent the user from using valid MS-DOS partitions?

# special DOS partition types (EFI, hidden, etc.) and RAID/LVM
# see http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
ENV{ID_PART_ENTRY_SCHEME}=="dos", \
  ENV{ID_PART_ENTRY_TYPE}=="0x0|0x11|0x12|0x14|0x16|0x17|0x1b|0x1c|0x1e|0x27|0x3d|0x84|0x8d|0x8e|0x90|0x91|0x92|0x93|0x97|0x98|0x9a|0x9b|0xbb|0xc2|0xc3|0xdd|0xef|0xfd", \
  ENV{UDISKS_IGNORE}="1"

# special GUID-identified partition types (EFI System Partition, BIOS Boot partition, RAID/LVM)
# see http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
ENV{ID_PART_ENTRY_SCHEME}=="gpt", \
  ENV{ID_PART_ENTRY_TYPE}=="c12a7328-f81f-11d2-ba4b-00a0c93ec93b|21686148-6449-6e6f-744e-656564454649|a19d880f-05fc-4d3b-a006-743f0f84911e|e6d6d379-f507-44c2-a23c-238f2a3df928|e3c9e316-0b5c-4db8-817d-f92df00215ae|de94bba4-06d1-4d40-a16a-bfd50179d6ac", \
  ENV{UDISKS_IGNORE}="1"
birdie-github commented 5 years ago

Is this project alive?

vpodzime commented 5 years ago

Is this project alive?

Yup. :) Sorry, I totally missed your issue. (you should have shouted sooner :wink:)

vpodzime commented 5 years ago

The rules are there to prevent desktop users from accidentally destroying their UEFI boot drives (both internal and external). Why do you need to use udisks to mount such partitions? Modifications of such data should be done by somebody with admin privileges.

It would be great if udisks supported much better configuration options (like enable_mounting_uefi = true), but then again, that would be in a root-owned configuration file.

vojtechtrefny commented 5 years ago

The UDISKS_IGNORE udev property only affects the HitIgnore property in the UDisks API. You can still mount "ignored" devices using UDisks API or udisksctl. The HintIgnore is used by GNOME/GVfs (and other GUI tools) to decided whether to show the device in the UI. We can change this for some devices (but I think it makes sense to hide EFI partitions) but this shouldn't be decided by us, but by GNOME and other users of the "ignore API".

birdie-github commented 5 years ago

The rules are there to prevent desktop users from accidentally destroying their UEFI boot drives (both internal and external). Why do you need to use udisks to mount such partitions? Modifications of such data should be done by somebody with admin privileges.

It would be great if udisks supported much better configuration options (like enable_mounting_uefi = true), but then again, that would be in a root-owned configuration file.

Maybe you're right. But it would be great to have an option to remove this limitation. E.g, a user might want to create (1) and populate (2) a UEFI system partition - currently it (2) can't be done unless you use sudo all the time.

tbzatek commented 5 years ago

Maybe you're right. But it would be great to have an option to remove this limitation. E.g, a user might want to create (1) and populate (2) a UEFI system partition - currently it (2) can't be done unless you use sudo all the time.

Well this is a two-fold problem. While I understand this is useful for USB stick ISO writers and similar tools, managing EFI partitions on removable media can be a security issue in fact. This is actually difficult to distinguish as long as it's possible to have EFI partition on a device that is classified as removable (USB stick, (e)MMC or SD cards, etc.) and the partition doesn't need to be mounted (e.g. /boot/efi) even if the system was actually booted from it. And we don't want regular users be able to destroy the system on some embedded or kiosk installations. Sadly the principle of seatings wouldn't help to distinguish things here.

I think this question deserves further evaluation - would be good to evaluate drive classifications on non-standard connections - eMMC, USB drives containing an OS (or several installations), etc.

Could you perhaps describe your use case a little bit more? I still do think any tools modifying system data even on removable devices should require proper authorization.