A post was merged into an existing topic: Whonix Software Signature Verification Documentation Discussion - VirtualBox vs KVM - GPG / signify / codecrypt
which probably won’t get any helpful directions on reddit.
Thanks for that. Hard to be everywhere at once to take on more complicated support issues.
Issue creating shared directory between host and guest reminds me…
chmod 777 /home/user/shared isn’t a great. Security issue and usability issue.
As per https://chmod-calculator.com/
public (i.e. any linux user account including those not having business there on the system) to read, write, execute files from that folder.
Is there some more canonical way to set up shared folders with KVM?
 Under which user is KVM attempting to write to shared folders?
 Under which group is KVM attempting to write to shared folders?
Perhaps better to create a folder elsewhere owned by that user  and group ?
user on the host should be able to read/write files there since Whonix KVM instructions currently include
sudo addgroup "$(whoami)" libvirt
sudo addgroup "$(whoami)" kvm
Then permissions to that folder could be hardened.
chmod --recursive **o**-rwx
users who are neither the file’s owner nor members of the file’s group
rwx - read, write, execute
I.e. remove read, write, execute for
others, i.e. no other user account than owner (
u) and group (
g) can read, write, execute there.
Then perhaps “the ultimate set” of commands could be provided that 100% made sure that all permissions are fine no matter how much the user messed that up.
sudo mkdir -p /shared sudo chown --recursive libvirt:kvm /shared sudo chmod --recursive o-rwx /shared sudo chmod --recursive ug+rw /shared
/shared (violating FHS, maybe the not shown in some file managers) or
/sharedis easier to create and fully control permission wise.
/mntmore standard conform but then user might mess up permissions of
Probably also fixable.
sudo mkdir -p /mnt sudo chown root:root /mnt sudo chmod o+r /mnt sudo chmod o+x /mnt
Untested. Please see if that can be made to work:
I was desperately getting them to work when I tried the currently documented steps. I never had any motive to improve them. Yes the current permissions are non-ideal, but I don’t know if they could harm security in practice.
I hesitate to experiment with my setup because I use it heavily every day and it would be a major PITA if it breaks down. If any user wants to try them out and report it works I would be willing to consider.
Yeah that was my main reason why I kept it in the user home folder. Didn’t want to risk messing something up on a system wide level.
Does Restrict Hardware Information to Root - Testers Wanted! work in Whonix KVM now in Whonix
Are we rolling out new point releases? If so then ill fire up a build VM.
Since no issues reported so far and unlikely any blockers will be identified in the next few days it looks like
220.127.116.11.2 will likely become the next point release indeed.
Indeed that happened.
I have no idea how moving vs copying is relevant to instruction validity. The steps still work, I know because I apply them every upgrade.
@Patrick the 18.104.22.168.3 images are live but the links are broken because they don’t take the new Intel_AMD naming into account. Can you please adjust the templates to allow for multiple archs?
Also gpg / signify verification instructions will need updating.
OK what is the stable version no.? Because in practice the main KVM download page always provided the latest point release.
22.214.171.124.3 can be stable whenever you’re comfortable / tested.
This time maybe KVM version will be release before VirtualBox version which is in the making but that’s alright. All packages are in the stable repo already anyhow.