https://github.com/QubesOS/qubes-core-agent-linux/pull/164
https://github.com/QubesOS/qubes-issues/issues/5110
https://github.com/QubesOS/qubes-issues/issues/5111
https://github.com/Samer-Al-iraqi/Linux-str_replace/issues/3
https://github.com/Samer-Al-iraqi/Linux-str_replace/issues/4
/etc/ld.so.preload.d drop-in configuration folder support
https://sourceware.org/bugzilla/show_bug.cgi?id=24838
Whonix template: /etc owned by user:user · Issue #1156 · QubesOS/qubes-issues · GitHub
I now figured out a general bug on Debian which can cause similar issues. This is what I did.
Installed apt-cacher-ng in TemplateVM.
sudo apt install apt-cacher-ngFolder
/var/cache/apt-cacher-ngwill be owned byapt-cacher-ng:apt-cacher-ngi.e. by userapt-cacher-ngand by groupapt-cacher-ng.Then in AppVM I added folder
/var/cache/apt-cacher-ngto bind-dirs. File/rw/config/qubes-bind-dirs.d/50_user.confcontents:binds+=( '/var/cache/apt-cacher-ng' )I then changed the underlying TemplateVM to a different Debian based TemplateVM which does not have apt-cacher-ng installed.
I wondered why apt-cacher-ng would fail to start after installed in AppVM and noticed that folder
/var/cache/apt-cacher-ngis now owned by an unrelated “random” non-root user/group other than apt-cacher-ng.Qubes mount-dirs seems to keep care about user ID changes when underlying TemplateVM changes but this is only for the /home folder.
This issue /etc being owned by a some (not so) “random” user
usermight have been caused by the same mechanism that can mess up owner/group?Possibly related? I wonder if we should port from
* useradd, groupadd and usermodto
* adduser and addgroupQuoted from Debian adduser manpage:
They are friendlier front ends to the low level tools like useradd, groupadd and usermod programs, by default choosing Debian policy conformant UID and GID values, creating a home directory with skeletal configuration, running a custom script, and other features.