Can you give some more context here? Is it the problem that user is created too early (before /etc/skel is fully populated)? Or is it a problem that it's created at all? Should there be a difference between Qubes and non-Qubes case?

In Qubes case, user is created by installing qubes-core-agent package. How is it done in non-Qubes case?

Is requirement of not creating user (if I understand correctly) a limitation of calamares, or is there some good reason behind it? 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.

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?

• http://blog.dailystuff.nl/2012/07/create-home-directory-on-first-login/
• sudo pam-auth-update --enable mkhomedir

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.

In T913#18744, @Patrick wrote:

Do you see any issues with "create home directory on first login" in Qubes?

Hmm, in fact, this is already the case. It is initialized from /etc/skel at VM first boot time. When initializing private volume. Looks like home dir created during template build time is moved to /home.orig and ignored. Artifact from <=R3.2 time when it was used to initialize actual home in private volume.

And in fact it is a problem some times. If you have whonix-15-dvm and never started it, private volume will be empty. And will be initialized at every Whonix DisposableVM start time. It caused such DisposableVMs to timeout during start, due to accumulated TB instances (https://github.com/QubesOS/qubes-issues/issues/4918). I'm not sure about good generic solution, other than "don't put a lot of files in /etc/skel or other places used to initialize home dir".

• http://blog.dailystuff.nl/2012/07/create-home-directory-on-first-login/
• sudo pam-auth-update --enable mkhomedir

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".

Makes sense. Although in Qubes there is still a code to do that at proper time (after mounting /home, but before starting any user process). And also handle UID change that may happen if you switch template.

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?

Mostly timestamps if you're not careful. But those will be different anyway, so probably can be ignored here. I was also thinking about some identifiers generated at application start time (like firefox profile id), but it is totally independent here: either those are included in /etc/skel and should be the same everywhere regardless of when it's copied. Or not included and will be different, also regardless of when home is initialized.
In short: not a problem.

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.

Yes, makes sense.

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.

In RPM there is %post and %posttrans. The later is run after all requested packages are installed. Not sure if there is any Debian equivalent.