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.
