How does my device or disk appears to devices list while being attached?

So, I discovered that some devices (i.e. phone’s virtual drive with drivers), which already attached to a VM, but somehow not being used (mounted?), appears in devices menu, so, we able to reattach them again or somewhere else.

I wonder how it works? Does it work with fuse?

I found this useful, so, if we can create one vm that encapsulates all mounted filesystems, crypto containers or anything, and exposes some drives to this menu to attach them somewhere else.

I know there is the Qubes Shared Folder but in current state it doesn’t work or even builds

So can anyone explain this behavior:

This is mounted veracrypt’s container.

Here I goes to unmount it with a file manager.


Here it seems to be unmounted, but the veracrypt’s utillity says otherwise and this unlocked container became system-wide exposed, so, you can attach it anywhere.

About the screenshots:

Could you try to provide step by step command-line outputs of qvm-block in dom0 and lsblk or losetup -l in the demonstration qube?

Before

dom0 | qvm-block

BACKEND:DEVID DESCRIPTION USED BY
zilch

lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 1M 0 loop
└─veracrypt1 253:0 0 768K 0 dm /media/veracrypt1

losetup -l

NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0 0 0 0 0 /home/user/demonstration 0 512

After

dom0 | qvm-block

BACKEND:DEVID DESCRIPTION USED BY
disp4806:dm-0 veracrypt1

lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 1M 0 loop
└─veracrypt1 253:0 0 768K 0 dm

losetup -l

NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0 0 0 0 0 /home/user/demonstration 0 512

I think we need to dig into these virtual block devices and mountpoint’s removal behavior.

1 Like

First, I want to say that I’m not able to explain how it works :slight_smile:

But I can try to give you a reproducible example, so your question will be: “How do loop devices appear in the devices list?”. Here we go:

  1. in a qube, create a basic loop device:

    truncate -s 100M example
    sudo mkfs -t ext4 example
    sudo losetup -f example
    
  2. in dom0, now you can see the loop device with qvm-block:

    BACKEND:DEVID   DESCRIPTION   USED BY
    disp1234:loop0  /home/user/example  
    
  3. In the first qube, mount the loop device (replace <NUMBER> by the correct number, probably 0):

    sudo udisksctl mount -b /dev/loop<NUMBER>
    
  4. in dom0, the block is unavailable,

  5. in the first qube, unmount the loop device (don’t forget to use the correct number):

     sudo udisksctl unmount -b /dev/loop<NUMBER>
    
    
  6. in dom0, the block is available.

Is this what we are talking about?

In a file manager, unmounting usually only closes the filesystem but does not close the underlying encryption layer (which, without an opened filesystem using it, now becomes available for attaching to another VM). So it’s normal that you still need to close the encryption layer through the VeraCrypt program. Confusingly, VeraCrypt also calls this operation “unmounting” because it will close the filesystem first if it is still open (meaning, you don’t actually need to unmount manually in the file manager) and then it will close the encryption layer too.

1 Like