© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f291340
demo site
(Get the code!)
There's a long history of bugs related to attempts to limit access to files/dirs in /var/lib/nova. Considering that this is the most recent bug opened that is related to this topic, I will leave a history summary here in case we need it in the future.
= (1) April 2020: change permissions of /var/lib/nova to 640 and 750 ==
In the focal development cycle we set file permissions under /var/lib/nova to 640 and directory permissions to 0750. That was done as part of an effort across all the openstack packages via LP: #1859422
For nova, that was handled in the following commit: https:/
= (2) April 2020: add libvirt-qemu to nova group =
As a result of the previous change, the following bug was opened because the libvirt-qemu user needed access to /var/lib/
To fix that, we added the libvirt-qemu user to the nova group, since /var/lib/nova is owned by nova:nova.
That was handled in the following commit: https:/
= (3) June 2020: change permissions of /var/lib/nova to 644 and 755 =
The previous changes turned out to cause access issues and the following bug was opened: "unable to start and stop an instance post ugprade": LP: #1885269
As a result we reset file permissions under /var/lib/nova to 644 and directory permissions to 0755.
That was handled in the following commit: https:/
= (4) Sept 2020: drop libvirt-qemu from nova group =
The following bug was opened due to instance snapshots being broken: LP: #1896617
Removing the libvirt-qemu user from the nova group fixed this.
This was handled in the following commits:
https:/
https:/
= (5) March 2022: don't change permissions of /var/lib/
We then had a bug opened as the 0644 permissions for '/var/lib/
That was handled in the following commit: https:/
= (6) April 2022: Permission denied when trying to resize instance after CIS hardening =
And finally, the current bug we're looking at was opened due to instance resizing failing on a CIS hardened machine.
As part of hardening the umask is set to 0027. Therefore, new file permissions get 640 mode set instead of 644. This causes an access denial for the libvirt-qemu user as it no longer has read access to the disk. For example:
ubuntu@
total 20816
drwxrwx--- 2 nova nova 4096 Aug 31 16:58 .
drwxr-xr-x 6 nova nova 4096 Aug 31 16:58 ..
-rw------- 1 root root 0 Aug 31 16:58 console.log
-rw-r----- 1 nova nova 21299520 Aug 31 16:58 disk
-rw-r----- 1 nova nova 79 Aug 31 16:58 disk.info