Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #267557 > unrolled thread

sudo udisksctl

Back to article view | Back to linux.debian.user

Contents

  sudo udisksctl Max Nikulin <manikulin@gmail.com> - 2024-02-18 04:30 +0100
    Re: sudo udisksctl David Wright <deblis@lionunicorn.co.uk> - 2024-02-18 05:50 +0100
      Re: sudo udisksctl Max Nikulin <manikulin@gmail.com> - 2024-02-18 06:50 +0100
        Re: sudo udisksctl David Wright <deblis@lionunicorn.co.uk> - 2024-02-19 05:40 +0100
          Re: sudo udisksctl Max Nikulin <manikulin@gmail.com> - 2024-02-19 18:00 +0100
            Re: sudo udisksctl David Wright <deblis@lionunicorn.co.uk> - 2024-02-21 19:50 +0100

#267557 — sudo udisksctl

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.

[toc] | [next] | [standalone]

#267560

On Sun 18 Feb 2024 at 10:23:52 (+0700), Max Nikulin wrote:
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#267561

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.

[toc] | [prev] | [next] | [standalone]

#267580

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.

[toc] | [prev] | [next] | [standalone]

#267590

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.

[toc] | [prev] | [next] | [standalone]

#267662

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web