Re: [qubes-users] Re: 0.1 BTC bugfix bounty

[David Hobach]

On 09/12/2018 04:51 PM, Stickstoff wrote:

On 09/11/2018 03:52 PM, Thomas Papenkort wrote:

I have run into the same problem for backups when switching to qubes 4.0 and
found this workaround:

     # a file cannot be attached if it is in directory /var/lib/qubes/appvms, 
so create a link first
     ln /var/lib/qubes/appvms/$1/private.img /home/user/private.img
     LOOPDEV=`sudo losetup -f`
     sudo losetup $LOOPDEV /home/user/private.img
     qvm-block attach -o frontend-dev=xvds -o read-only=true backupvm dom0:$(basename 
"$LOOPDEV")

[backup happens here]

     qvm-block detach backupvm dom0:$(basename "$LOOPDEV")
     sudo losetup -d $LOOPDEV
     rm /home/user/private.img

Thank you a lot for your help!
I got it to work finally. In fact, it's a combination of the two details:
- get the .img file to another path. It can't stay in
"appvms/VMNAME/private.img". Get a hardlink elsewhere, or rename
"appvms" (and "vm-templates"), both are fine.
- you still have to delete the .qubes-exclude-block-devices file, if you
renamed "appvms" or the path to your hardlink contains this file.

Below in bash what I use since at least 4.0rc1.







KR
David

----------------------

#createDomZeroLoopDeviceIfNecessary [dom0 path]

function createDomZeroLoopDeviceIfNecessary {
local domZeroPath="$1"

#do we have a previously used device?
local oldDev="$(losetup -j "$domZeroPath" | grep -Eo '^/dev/loop[0-9]+')"

if [ -n "$oldDev" ] ; then
        echo "$oldDev"
else
        #no old device --> create a new one
        #we use the exit code as ours
        sudo losetup -f --show "$domZeroPath"
fi
}

#getVMDeviceNameForAttached [device in dom0] [VM]

function getVMDeviceNameForAttached {
local dev="$1"
local vm="$2"
local regex="^dom0:$dev\s+.*\s+${vm}\s+\(.*frontend-dev=([a-z0-9]+).*\).*$"

#run the regex against qvm-block & return the result
qvm-block l | sed -r -n "s/$regex/\\1/p"
}


function qvmBlockAttachFromDomZeroTo {
local result="$1"
local path="$2"
local targetVM="$3"
local empty=""
local dev=""
local rwOption=""
[ $4 -eq 1 ] && rwOption="-o read-only=yes"

#default = error
eval $result="'$empty'"


local pfile="$DOM0_TEMP_DEV_PATH/$(echo "$path" | md5sum | cut -d " " -f1)"
ln "$file" "$pfile"

Anyway what you're describing is considered a feature, not a bug (I recall when it was introduced as part of a bug report I had made in the beginning of 4.0rc1 about qvm-block not supporting files at all). I think it was a udev rule one-liner checking the path back then. I'd suggest creating a feature request for a force flag bypassing it and maybe mention that you'd be willing to donate for that. I'm not sure whether it's meant to be officially supported though as they might go away from sparse files with the recent introduction of qvm-pool etc. (wild guess). #returns: created loop device or previously used one (incl. /dev/); sets a non-zero exit code, if no device could be created #create a loop device from the given file path in dom0, if necessary (no old one does exist) #get the name for the device created in the given VM during execution of the qvmBlockAttachFromDomZeroTo function #returns: name of the attached device in the given VM (without the /dev/ prefix) or an empty String, if no such device exists (not attached anymore) #qvmBlockAttachFromDomZeroTo [result] [source path in dom0 (must be a file)] [target VM to attach the source path to] [optional: ro flag] #[ro flag]: optional flag, that - if set to 1 - makes sure the file is attached as read-only to the target VM #returns: device created in the VM as the result variable or an empty result variable in the case of errors #we need to create a pseudo file as Qubes 4.0rc1 will attempt to prevent qvm-block usage for its private.img files #hard links work to bypass that, but need to be on the same drive (/tmp doesn't work) #unfortunately qvm-block l has issues for files, so we create a loop device first and use that one #also see: R3.0: qvm-block doesn't work well on files (https://groups.google.com/forum/#!msg/qubes-users/IotETu-gsm4/FO2GOu5pBwAJ)

#for 4.0rc1 I'm not even sure whether it supports files...
dev="$(createDomZeroLoopDeviceIfNecessary "$pfile")"
[ $? -ne 0 ] && return
dev="${dev/\/dev\//}"

#run qvm-block
qvm-block a $rwOption "$targetVM" "dom0:${dev}"
[ $? -ne 0 ] && return

#get the return value and update the return var
lastAttached="$(getVMDeviceNameForAttached "$dev" "$targetVM")"
eval $result="'$lastAttached'"
}

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7a79d289-656c-21fc-2c06-c1a91f7d6c97%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature