Authentification required but x-udisks-auth option is NOT defined in fstab

[Lavande-aspic]

When trying to mount an ntfs partition in my graphical file explorer (dolphin or krusader) on fedora 36, I get asked for the admin password. Here are the displayed details:

Action: Mount/unmount filesystems defined in the fstab file with the x-udisks-auth option
ID: org.freedesktop.udisks2.filesystem.fstab
Vendor: The Udisks Project
polkit.subject-pid: 3108
polkit.caller-pid: 1013

The x-udisks-auth option is NOT specified in my fstab.

LABEL=windows /mnt/windows ntfs-3g defaults,users,noauto 0 0

I went over the ntfs-3g FAQ and I can mount the partition as an unprivileged user using udisksctl mount -b /dev/sdb4 /mnt/windows/.

I did have to add suid root to udisksctl doing the following:

❯ ls -l  $(which udisksctl)
-rwxr-xr-x. 1 root root 62368 Mar  3 16:41 /usr/bin/udisksctl*
❯ sudo groupadd udisksmount                                                           
❯ sudo chown root:udisksmount $(which udisksctl)
❯ sudo chmod 4750 $(which udisksctl)                                                   
❯ sudo usermod -aG udisksmount nox                     
❯ ls -l  $(which udisksctl)
-rwsr-x---. 1 root udisksmount 62368 Mar  3 16:41 /usr/bin/udisksctl*

Where does the x-udisks-auth option get called ?

[vojtechtrefny]

The x-udisks-auth option is NOT specified in my fstab.

The description for the polkit action doesn't really make sense here, it's not realated to the x-udisks-auth option at all, it means: "we tried to mount the device referenced in fstab as the calling user and failed so we are now asking for root permissions". But it's still weird, we apparently found the fstab entry, parsed it correctly and also found the users option. Can you share output of udisksctl info -b /dev/sda4? Also does mounting with mount works as a non-root user? With users in /etc/fstab simply running mount /dev/sda4 should work.

[Lavande-aspic]

Thank you for the polkit action translation. Here is the asked output:

❯ udisksctl info -b /dev/sdb4
/org/freedesktop/UDisks2/block_devices/sdb4:
  org.freedesktop.UDisks2.Block:
    Configuration:              [('fstab', {'fsname': <b'LABEL=windows'>, 'dir': <b'/mnt/windows'>, 'type': <b'ntfs-3g'>, 'opts': <b'defaults,users,noauto'>, 'freq': <0>, 'passno': <0>})]
    CryptoBackingDevice:        '/'
    Device:                     /dev/sdb4
    DeviceNumber:               2068
    Drive:                      '/org/freedesktop/UDisks2/drives/CT500MX500SSD1_1914E1F7DBFB'
    HintAuto:                   false
    HintIconName:               
    HintIgnore:                 false
    HintName:                   
    HintPartitionable:          true
    HintSymbolicIconName:       
    HintSystem:                 true
    Id:                         by-id-ata-CT500MX500SSD1_1914E1F7DBFB-part4
    IdLabel:                    windows
    IdType:                     ntfs
    IdUUID:                     F6304A1B3049E36B
    IdUsage:                    filesystem
    IdVersion:                  
    MDRaid:                     '/'
    MDRaidMember:               '/'
    PreferredDevice:            /dev/sdb4
    ReadOnly:                   false
    Size:                       146028888064
    Symlinks:                   /dev/disk/by-id/ata-CT500MX500SSD1_1914E1F7DBFB-part4
                                /dev/disk/by-id/wwn-0x500a0751e1f7dbfb-part4
                                /dev/disk/by-label/windows
                                /dev/disk/by-partlabel/Basic\x20data\x20partition
                                /dev/disk/by-partuuid/c046e221-97f4-402e-9c6b-5b7be7cb659f
                                /dev/disk/by-path/pci-0000:01:00.1-ata-2-part4
                                /dev/disk/by-path/pci-0000:01:00.1-ata-2.0-part4
                                /dev/disk/by-uuid/F6304A1B3049E36B
    UserspaceMountOptions:      
  org.freedesktop.UDisks2.Filesystem:
    MountPoints:        
    Size:               0
  org.freedesktop.UDisks2.Partition:
    Flags:              0
    IsContained:        false
    IsContainer:        false
    Name:               Basic data partition
    Number:             4
    Offset:             677380096
    Size:               146028888064
    Table:              '/org/freedesktop/UDisks2/block_devices/sdb'
    Type:               ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
    UUID:               c046e221-97f4-402e-9c6b-5b7be7cb659f

Also does mounting with mount works as a non-root user? With users in /etc/fstab simply running mount /dev/sda4 should work.

Alas mounting as an unprivileged user doesn't work without adding said user to the disk group.

❯ mount /dev/sdb4 /mnt/windows
mount: /mnt/windows: must be superuser to use mount.
       dmesg(1) may have more information after failed mount system call.
❯ dmesg | grep sdb4                                                                                                                                                                 
[    1.450690]  sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6

Even when the unprivileged user is in the disk group and I can mount the partition using mount, I still get asked for the password from udisks when mounting in the gui file explorer.

❯ groups nox
nox : nox disk wheel ntfsuser udisksmount
❯ mount /dev/sdb4 /mnt/windows
❯ lsblk -o name,mountpoint,size,label,fstype,uuid | grep windows
├─sdb4 /mnt/windows   136G windows      ntfs   F6304A1B3049E36B

Now these changed: polkit.subject-pid: 4388 polkit.caller-pid: 1014

I do not, however wish to keep my user in the disk group, since that looks like a wonky workaround and I can mount using udisksctl on the cli.

[vojtechtrefny]

Alas mounting as an unprivileged user doesn't work without adding said user to the disk group.

Ok, that explains that. UDisks uses libmount and we try to behave the same way mount does. If we find user or users in fstab we basically let (lib)mount to deal with that so if mount doesn't work when called as a non-root user, it's not a surprise that udisks fails too. (Edit: That's apparently a known issue with ntfs-3g, I just never heard about that before.)

It probably doesn't make sense to make some special exception for ntfs-3g now when ntfs3 is a thing (that unfortunately also doesn't work with UDisks properly, see #932).

[Lavande-aspic]

Yes but the weird thing is that when I can use mount as unprivileged user, udisks (gui that is) still doesn't work. Well it should be easily patch-able (didn't manage it without the dirty add user to disk group workaround).

Ah well. The thing that puzzles me the most is that on ubuntu 20.04 it everything works out of the box.

[tbzatek]

I did have to add suid root to udisksctl doing the following:

Congratulations, you've just created a security hole in your system!

Yes but the weird thing is that when I can use mount as unprivileged user, udisks (gui that is) still doesn't work.

I think it's about the wrong secondary groups matching in UDisks, we've seen that before. See #818

Well it should be easily patch-able (didn't manage it without the dirty add user to disk group workaround).

You'll still need the disk group membership, otherwise there's no way to read data from the block device. There's nothing dirty about it.

(Edit: That's apparently a known issue with ntfs-3g, I just never heard about that before.)

Now that is a good argument for ntfs3!

[giuliohome]

You'll still need the disk group membership, otherwise there's no way to read data from the block device.

Yep ... another approach would be unauthenticated mounting, but personally I would avoid it (maybe for security concerns too).

Edit Spoiler: I'm using udisksctl mount ... by typing my password.

[tbzatek]

Yep ... another approach would be unauthenticated mounting, but personally I would avoid it (maybe for security concerns too)

Yeah, this is just another example of abusing tools to overcome limitations that have been put in place for a reason. There are many examples like this all around the internet. This is perfectly fine if the person making such modification is aware of possible consequences or in special cases (think of embedded). Blindly copy-pasting random snippets is always a recipe for disaster. In most cases upstream projects are even unaware of this happening out in the world.

[giuliohome]

Though, if you follow up the thread I linked from ask fedora forum, you can see I initially suggested adding the disk membership but I also reported the comment by Lahwaacz about it.

Edit

Blindly copy-pasting random snippets...

Absolutely not what I am doing. On the opposite, I'm saying that the disk group is for privileged users like root and not for normal users, hence my snippet contains udisksctl, etc...

[giuliohome]

Cc-ing @lahwaacz (referenced from website in https://wiki.archlinux.org/title/User:Lahwaacz)