[Help Welcome] KVM Development - staying the course

A post was merged into an existing topic: Whonix Software Signature Verification Documentation Discussion - VirtualBox vs KVM - GPG / signify / codecrypt


1 Like


1 Like


Due to

which probably won’t get any helpful directions on reddit.

1 Like

Thanks for that. Hard to be everywhere at once to take on more complicated support issues.

1 Like


1 Like

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/ 777 allow 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?

[1] Under which user is KVM attempting to write to shared folders?

[1] Under which group is KVM attempting to write to shared folders?

Perhaps better to create a folder elsewhere owned by that user [1] and group [2]?

I guess libvirt:kvm?

Then user 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

- remove

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 /mnt/shared?

  • /shared is easier to create and fully control permission wise.
  • /mnt more standard conform but then user might mess up permissions of /mnt folder.

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.

1 Like

Since no issues reported so far and unlikely any blockers will be identified in the next few days it looks like will likely become the next point release indeed.

1 Like

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 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?

1 Like

Fixed KVM Testers Only Version - Whonix with:
Difference between revisions of "KVM Testers Only Version" - Whonix

Also gpg / signify verification instructions will need updating.

1 Like

OK what is the stable version no.? Because in practice the main KVM download page always provided the latest point release.

1 Like 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.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]