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?
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.
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.
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:
Visual Studio Code - when using the vscode-cpptools extension to Visual Studio Code, when /home/.../foo.c is fed to the (closed source) language server, any problems found are reported in /var/home/.../foo.c and opened in a different editor window.
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: