-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Dec 25, 2019 at 05:53:28PM -0500, Demi M. Obenour wrote:
> On 2019-12-25 03:33, Marek Marczykowski-Górecki wrote:
> > On Wed, Dec 25, 2019 at 03:00:36AM +0000, 'heombeeh' via qubes-devel wrote:
> >> Thanks a lot for these clarifications.
> >
> >> Based on your recommendation against handling filesystem images within
> >> dom0, I'm thinking that I can instead create a "light storage" AppVM. This
> >> VM can simply have a directory of sparse files together with associated
> >> loop devices, and I can then attach them to other AppVMs normally using
> >> qvm-block.
> >
> > Sounds good.
> >
> >> However, just as in dom0, it will be good to protect this "light storage"
> >> VM from those client VMs that utilize its filesystem blocks. Can I protect
> >> this VM similarly to how dom0 is protected by using similar udev rules?
> >
> >> For example, suppose I keep my sparse files in
> >> `/home/user/myimages/{name}/disk.img`, and then add the following udev
> >> rule:
> >
> >> $ cat /etc/udev/rules.d/00-qubes-ignore-devices.rules
> >> ACTION!="remove", SUBSYSTEM=="block", KERNEL=="loop*",
> >> ATTR{loop/backing_file}=="*/myimages/*/*.img*",
> >> ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}="1",
> >> ENV{UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG}="1"
> >
> > That should do.
> > It is a bit fragile, because newer udev version could ship rules
> > ignoring those settings (yet another reason why updating dom0 isn't
> > straightforward), but in the current version it is still effective.
> >
> >> With this active, it seems to work:
> >
> >> $ sudo losetup --find --show ./myimages/blah/disk.img
> >> /dev/loop0
> >> $ lsblk -f /dev/loop?
> >> NAME FSTYPE LABEL UUID MOUNTPOINT
> >> loop0
> >
> >
> >> Is this enough to protect this "light storage" VM from the other VMs that
> >> attach to the filesystem images?
> >> Are there any other precautions that I should configure for this VM?
> >
> >> As I encountered with dom0, using the rule above prevents Qubes from
> >> detecting the loop devices associated with the disk image file. Using
> >> similar commands as shown in the docs you linked, I fixed this with:
> >
> >> $ qubesdb-write /qubes-block-devices/loop0/desc 'disk.img'
> >> $ qubesdb-write /qubes-block-devices/loop0/size 536870912
> >> $ qubesdb-write /qubes-block-devices/loop0/mode w
> >
> >> After doing this `qvm-block ls` detects the new disk, but the Qubes GUI
> >> (i.e. the widget in the top right corner of the window manager) does not
> >> detect the change. How can I trigger a "refresh" so that the GUI sees my
> >> changes to qubesdb?
> >
> > Do empty write to /qubes-block-devices:
> >
> > qubesdb-write /qubes-block-devices ''
> >
> >
>
> Is it safe to use the hotplug scripts built in to QubesOS? I am
> thinking of writing a udev rule that prevents the loop device from
> being parsed, but still runs the Qubes hotplug scripts so that the
> device shows up in the GUI.
Yes, it should be safe. The script doesn't access content of the device,
it only uses whatever is already available in udev and sysfs.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl4D8fIACgkQ24/THMrX
1yxRmQf/R3as1SV1Xiu4R/GCEf7UwLvmucUNYZVXZzVc/aSoAdNPHFec4FtosCJ1
/QjKf8hctrwdLf4yqG62I3Xa3vQHd49gkUkm9U03U06BySA5pPEQ/ZSP75CMl7iJ
ARnUdxKxrtTOuM23kRlnGYZe4UpwjBzxnM12SDyV+Y/3MsKmB0mYBYm3xZFnZ3qX
/K46EpIVtL/esvLPEcTX0zW8yPD+k4hJq3YWqA43QVfjRnCUHxZvblB5ZNYTegtZ
A8cOVmqYXAckXI1LOcFouOlfd/i+wS0RqZAOFDM4HwXrKvm7HPjwVFbqhYB0xvw3
xWvWtY6gGBa74Ytn0yz/PwoU/9umJw==
=61av
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20191225233411.GH25235%40mail-itl.
