Adapting user home in /etc/passwd

With ~ now residing in /var/home/ (primary), this should maybe be updated, as this for example rose my issue below:

Drawbacks could be compatibility issues when copying the home directory back on a non-ostree’d system. But I really don’t know why anyone would ever do that…? I don’t know if this could introduce other bugs – maybe it would be safer not to do that, but then we get some kind of split-problems here… Thoughts?

// Ok, I just tried this and wasn’t able to log in in GDM anymore… but maybe it’s reasonable to look into that?

1 Like

I have issues with making home as /var/home. Mostly because accounts will be created to be in /home/username and most installations mount /home anyway. It should be ok to mount /home to / even though it is read-only, right?

It comes down to files and paths being resolved with realpath. Paths that most people use will be /home/username/…/directory and then realpath will translate to /var/home/username/…/directory.

I think it’s pretty clear that having $(realpath $HOME)) != $HOME is not a viable situation - it creates whole classes of unnecessary bugs. (As a few examples: the Dropbox and Bluejeans flatpaks basically don’t work without workarounds, and Visual Studio Code gets confused as well.)

Possible solutions:

  • Make /home a bind mount instead of a symlink, as I think you are suggesting.
  • Write entries in /etc/passwd to reference the real home directory rather than /home as zyklon suggested

We’d need to check in with Colin Walters to get some historical background as to why /home is a symlink rather than a bind mount.

(We could also potentially do a Flatpak-specific fix when setting up the Flatpak environment while leaving the host system as is, but I think this is distinctly less good.)

Make /home a bind mount instead of a symlink, as I think you are suggesting.

This would probably be better as an ostree issue; the forum is OK for high level discussion and particularly cases like this where we’re not necessarily sure which component would be a good fit (or where we want to change two things at the same time, etc.).

But anyways briefly: It isn’t just /home that the “ostree model” takes over, it’s also e.g. /root and /mnt and /usr/local and a bunch of things. So any special casing for /home wouldn’t help any similar issues for those other directories.

That said, clearly /home is important and worth trying to improve.

The main problem with making it a bind mount is that one can’t do rename() across them even if they’re on the same filesystem…so anyone (like me) who has e.g. /home/ and /srv or whatever that are actually on the same device (I just have /var as a separate partition, so those are /var/home and /var/srv), suddenly wouldn’t be able to move files across them without copying. I think there were some kernel patches for this at some point but…

Agreed. I hope a solution can be found for all such links. It is just that /home causes the most consternation because of passwd. I have other scenarios besides Dropbox or Bluejeans where it breaks things for me.

IMHO, passwd should not be adapted to user home in /var, but another solution to symlinks should be found.

Right, see base: Use /var/home for home directories by default by cgwalters · Pull Request #18 · coreos/fedora-coreos-config · GitHub

I can cross-link this thread there but a little bit more detail about what exactly fails would be helpful. (Seems like software should be able to handle symlinks)

Maybe it’s something like software wanting to detect “is path X in the home directory” and doing that as a string prefix comparison with $HOME?

It’d be a bit more general to do something like calling realpath(/home) when adding a user. Though I just opened the libuser source code and…okay wow…layers and layers of abstraction.

EDIT: Submitted PR#121: post: Make HOME=/var/home by default - workstation-ostree-config - Pagure.io

I can cross-link this thread there but a little bit more detail about what exactly fails would be helpful. (Seems like software should be able to handle symlinks)

The examples I have are all in closed-source software, so the details are a bit fuzzy:

These are all quite arguably bugs in the software - but if we can avoid triggering such bugs, we’re going to make things smoother for the user.

A source of strange behavior Flatpak in particular can be seen by:

$ pwd
/home/otaylor/Source
$ bwrap --bind / / pwd
/var/home/otaylor/Source

I ran into this issue with both vscode and vim for Go. Just like your case with cpp, Go tools also get confused with /var/home and /home.

In case this benefits anyone else, my workaround for now is to make /var/home my working directory in the terminal before launching vim or vscode.