sudo udisksctl

[Max Nikulin]

I have decided to ask the following in a separate thread.

On 17/02/2024 02:59, David Wright wrote
(Re: f3tools vs Silicon Power 4T drive):
> lulu ()
> {
> sudo udisksctl unlock --block-device /dev/disk/by-partlabel/Lulu01 && mount /media/lulu01
> }

I am evaluating if udisks2 D-Bus API allows to create a tool as
convenient as pmount(1) that is smart enough to unlock a device before
mounting it (optionally with specified name of mountpoint)

pmount /dev/sda1 mybackup

I have puzzled by your function however. I believed that udisks was
created to allow *regular* users to mount drives. If you are using sudo
why do not you use "cryptsetup open" directly? Otherwise udisksctl can
ask password if policy does not allow disk operations for the current user.

P.S. Unfortunately mount name is hardcoded in udisksd. It is either
label or UUID, it can not be specified when a partition is mounted.

[David Wright]

Because policykit allows me to unlock partitions only if they're
local. I rely on being able to unlock partitions remotely. For
example, if I wakeonlan the PC in the basement, I need to be able
to unlock its /home before I can login as myself.

As a demonstration:

$ hostname
bhost
$ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01
Passphrase:
Unlocked /dev/sdc1 as /dev/dm-2.
$ udisksctl lock --block-device /dev/disk/by-partlabel/Nokia01
Locked /dev/sdc1.
$

is fine, but ssh to a laptop and back to this machine:

$ ssh ahost
Linux ahost 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64
[ … ]
You have new mail.
Last login: Sun Feb 18 04:18:39 2024 from 192.168.1.14
$ ssh bhost
Linux bhost 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64
[ … ]
You have new mail.
Last login: Sun Feb 18 04:18:44 2024 from 192.168.1.16
$ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01
Passphrase:
==== AUTHENTICATING FOR org.freedesktop.udisks2.encrypted-unlock ===
Authentication is required to unlock the encrypted device Multiple Card Reader (/dev/sdc1)
Authenticating as: root
Password:
[ pressed ^C ]

That's what I'm avoiding with sudo.

Cheers,
David.

[Max Nikulin]

On 18/02/2024 11:40, David Wright wrote:
> $ ssh bhost

> $ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01
> Passphrase:

> ==== AUTHENTICATING FOR org.freedesktop.udisks2.encrypted-unlock ===
> Authentication is required to unlock the encrypted device Multiple Card Reader (/dev/sdc1)

It should be possible to modify policy to allow a specific user or a
group to perform disk operations, see polkit(8). When sudo is involved,
I still do not see any advantage of udiskctl over "cryptsetup open". As
third option, if I remember it correctly, pmount relies on group
membership, not on systemd-logind "uaccess", so local vs. remote user
should not matter. This variant combines unlock and mount into a single
command.

[David Wright]

On Sun 18 Feb 2024 at 12:41:29 (+0700), Max Nikulin wrote:
> On 18/02/2024 11:40, David Wright wrote:
> > $ ssh bhost
> > $ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01
> > Passphrase:
> > ==== AUTHENTICATING FOR org.freedesktop.udisks2.encrypted-unlock ===
> > Authentication is required to unlock the encrypted device Multiple Card Reader (/dev/sdc1)
>
> It should be possible to modify policy to allow a specific user or a
> group to perform disk operations, see polkit(8).

This is basically a single-user network here, and I simplify matters
by keeping all the permitted privileged operations in one place,
under sudoers.d/. I'm happy to let policykit look after the way that
system components work together, but I'm not interested in getting
involved in that stuff myself. The flexibility in configuration,
desirable in multiuser systems, comes with a learning curve that
I'm not interested in climbing.

> When sudo is
> involved, I still do not see any advantage of udisk[s]ctl over
> "cryptsetup open".

I'd be more worried about disadvantages. About the only difference
I see is that cryptsetup open requires a name.

> As third option, if I remember it correctly, pmount
> relies on group membership, not on systemd-logind "uaccess", so local
> vs. remote user should not matter. This variant combines unlock and
> mount into a single command.

That would be pointless for me. After udev creates correctly-named
mountpoints using my rules, entries in fstab set the appropriate
flags for each individual device. That contradicts the expressed main
purpose of pmount: "permits normal users to mount removable devices
without a matching /etc/fstab entry." — precisely what I don't want.

Cheers,
David.

[Max Nikulin]

David, feel free to stop discussion if you find me annoying. My problem
in some sense is close to your one and I am trying to figure out if
missed some udisks feature and the result is some inconvenience.

On 19/02/2024 11:26, David Wright wrote:
> On Sun 18 Feb 2024 at 12:41:29 (+0700), Max Nikulin wrote:
>> On 18/02/2024 11:40, David Wright wrote:

>>> $ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01

>
>> When sudo is
>> involved, I still do not see any advantage of udisk[s]ctl over
>> "cryptsetup open".
>
> I'd be more worried about disadvantages. About the only difference
> I see is that cryptsetup open requires a name.

I find it convenient to have a meaningful name in /dev/mapper in
addition to /dev/dm-X. So I would not call it pure disadvantage.

>> As third option, if I remember it correctly, pmount
>

> That would be pointless for me. After udev creates correctly-named
> mountpoints using my rules, entries in fstab set the appropriate
> flags for each individual device. That contradicts the expressed main
> purpose of pmount: "permits normal users to mount removable devices
> without a matching /etc/fstab entry." — precisely what I don't want.

I consider pmount as a tool does not need separate unlock and mount
commands, so a shell function becomes unnecessary. In respect to
permissions (for removable drives) it acts as a substitute for sudo.

I expected that you need to mount a partition under /media into the
directory with name taken from filesystem LABEL. If so then udisksd can
do it and /etc/fstab entry is unnecessary. You anyway added an udev
rule. The following one should change mountpoint from
/media/$USER/lulu01 to /media/lulu01

SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="lulu01",
ENV{UDISKS_FILESYSTEM_SHARED}="1"

It seems that mixing of udisksctl and non-udisksctl commands cat be avoided.

[David Wright]

On Mon 19 Feb 2024 at 23:53:41 (+0700), Max Nikulin wrote:
> David, feel free to stop discussion if you find me annoying. My
> problem in some sense is close to your one and I am trying to figure
> out if missed some udisks feature and the result is some
> inconvenience.
>
> On 19/02/2024 11:26, David Wright wrote:
> > On Sun 18 Feb 2024 at 12:41:29 (+0700), Max Nikulin wrote:
> > > On 18/02/2024 11:40, David Wright wrote:
> > > > $ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01
> >
> > > When sudo is
> > > involved, I still do not see any advantage of udisk[s]ctl over
> > > "cryptsetup open".
> >
> > I'd be more worried about disadvantages. About the only difference
> > I see is that cryptsetup open requires a name.
>
> I find it convenient to have a meaningful name in /dev/mapper in
> addition to /dev/dm-X. So I would not call it pure disadvantage.

True, it makes the NAME in lsblk shorter. But the only time I've
defined a name is when opening the partition tocreate the filesystem:

# cryptsetup --align-payload 2048 luksFormat /dev/sdz9

WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
# cryptsetup luksAddKey /dev/sdz9
Enter any existing passphrase:
Enter new passphrase for key slot:
Verify passphrase:
# cryptsetup open --type luks /dev/sdz9 thename
Enter passphrase for /dev/sdz9:
# ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 Aug 18 10:35 control
lrwxrwxrwx 1 root root 7 Aug 18 10:35 thename -> ../dm-0
# ls -l /dev/dm-0
brw-rw---- 1 root disk 254, 0 Aug 18 10:35 /dev/dm-0
# mkfs.ext4 -L name09 /dev/mapper/thename
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 105966668 4k blocks and 26492928 inodes
Filesystem UUID: 3c832120-d40a-4998-b927-1318eb1e17f8
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

# e2label /dev/mapper/thename name09 (if forgotten above).
#

[ … creating, chown-ing, chmod-ing top-level directories ]

# cryptsetup luksClose thename
#

> > > As third option, if I remember it correctly, pmount
> >
> > That would be pointless for me. After udev creates correctly-named
> > mountpoints using my rules, entries in fstab set the appropriate
> > flags for each individual device. That contradicts the expressed main
> > purpose of pmount: "permits normal users to mount removable devices
> > without a matching /etc/fstab entry." — precisely what I don't want.
>
> I consider pmount as a tool does not need separate unlock and mount
> commands, so a shell function becomes unnecessary. In respect to
> permissions (for removable drives) it acts as a substitute for sudo.
>
> I expected that you need to mount a partition under /media into the
> directory with name taken from filesystem LABEL. If so then udisksd
> can do it and /etc/fstab entry is unnecessary. You anyway added an
> udev rule. The following one should change mountpoint from
> /media/$USER/lulu01 to /media/lulu01
>
> SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="lulu01",
> ENV{UDISKS_FILESYSTEM_SHARED}="1"
>

> It seems that mixing of udisksctl and non-udisksctl commands can be avoided.

I hadn't thought about that as an issue. I've just chosen, for
each step, the method that's most convenient (for me). See:

https://lists.debian.org/debian-user/2024/01/msg00737.html

for some details of the first step, which I won't duplicate here.
I group-control the directory /etc/udev/rules.d/my-mountpoints,
hence all the 59 entries.

For decrypting, I use either the PARTLABEL or the device-ID. The
latter's useful for sticks and cards that I wipe more frequently,
which makes the other symlinks variable over time.

For mounting, I use fstab entries because they have the flags defined,
rather than putting them in the mount command. When I need to mount
with sudo, the flags include a private x-mysudo flag, which is picked
up by my wrapper around mount. (The bash function that started this
discussion doesn't say "mount /media/lulu01" but "mmm /media/lulu01".)

Unmounting is also wrapped, not just for sudo, but because it contains
a script to updatedb (for locate), ls -lR (for mc), and create a
listing (using find) that lists modification time, size and filename
in a customised format. After any locking, the three products are
automatically transferred to my other hosts to keep them up-to-date.

It probably all looks hackish to someone running a multiuser system.

Cheers,
David.