! In T913#18743, @marmarek wrote:
Can you give some more context here?
Is it the problem that user is created too early (before /etc/skel is fully populated)?
Yes.
[1] /etc/skel is not fully populated by the time.
anon-base-files postinst (which creates user “user”) runs at a “random” time. I.e. not at a fixed time. There is no mechanism to say “install this package last - after all packages that write into /etc/skel have been installed”.
Or is it a problem that it’s created at all?
Not sure yet but possibly not.
Should there be a difference between Qubes and non-Qubes case?
Ideally, not.
After more research / testing I was considering to submit a pull request for qubes-core-agent linux maintainer scripts to make these configurable so these wouldn’t create user user so this could be left to the derivative (here: Whonix). (Should be easy. “If this file exists, skip this code.”)
Although this wouldn’t work perfectly. Since the template build process is roughly create Debian base image, Qubesify them, Whonixify them, there is no way Whonix could ship a config/status file to disable qubes-core-agent-linux user user creation. But not a big deal either. Some solution? Some existing environment variable? As fallback Whonix could also during build delete user user and/or home folder and then use its own code for that.
Switching the build process to create Debian base image, Whonixify them and Qubesify at the end may not be great either since then the Whonix packages can’t easily detect it’s going to be a Qubes environment or? A lot work, potential breakage?
In Qubes case, user is created by installing qubes-core-agent package. How is it done in non-Qubes case?
anon-base-files postinst
Is requirement of not creating user (if I understand correctly) a limitation of calamares, or is there some good reason behind it?
Calamares was one, later added, reason but we might find a way to overcome that. (Trying to avoid a special case for that too.)
[1] (/etc/skel is not fully populated at user user creation time) was the original and main reason for this ticket.
I see creating user at first-boot time (instead of build time) as unnecessary slowing down the process, and yet another place potentially resulting in unique per-installation identifiers being created.
Hm, good point. I didn’t have that one in mind.
Ideally, as much as possible the standard ways to do things can be utilized without any special cases Qubes vs non-Qubes. Having custom /etc/skel to user home population code is really not great.
Do you see any issues with “create home directory on first login” in Qubes?
That was my latest idea. Create user user with --no-create-home by default at build time and then “create home directory on first login”.
The current file list shouldn’t take more than a second to copy?
Unique per-installation identifiers… What could that be? Different user id (id user) per installation?
I was on a different train of thought: shipping without /home folder makes reproducible builds slightly easier since less files which are not owned by any package.
Or do you know any way to do “install this package last”, so user user creation could be done after /etc/skel for sure is fully populated? It would be easy to do with a chroot script but we got rid of chroot scripts. Therefore “sudo apt install whonix” is now possible and being done in the wild.