I see. Figured it was more complicated right after replying.
Just an idea: why not mounting the home area at its original place inside the container? I understand that it may clash with another directory already present on image, but you could deal with these cases, instead of trying a universal solution. I fully understand that an elegant, “all cases” solution is the way to go, but implementing some kind of “pre check” for clashes before launching the snap would suffice for most cases, don’t? If somebody places its home in a completely awkward path, they would’ve problems much earlier than launching snaps.
Anyway, thanks for you time. Will keep an eye on this, see if it is eventually solved.
We cannot easily create new directories inside the runtime environment. The runtime is the base snap designated by the snap developer or, as a fallback, the core snap.
The core snap has the /home and the /root directory so we can easily bind mount those. It doesn’t have the “arbitrary value stored in gecos (/etc/passwd)
I think the idea with mounting arbitrary HOME of a specific user to /var/home/LOGNAME is workable but it is complex and has some UX consequences. Another question is how to introduce that without breaking users. Perhaps only for values of HOME outside of /home or /root
That’s why I suggested mounting it at its original place. I made some experiments some time ago, using Docker to do exactly this: launch applications. I’ve solved some of these problems by using a custom entrypoint, that would make some adjustments (in this case, creating the custom home dir, if doable, e.g.), and then calling an standard exec script, that would launch the real application. Just another idea…
Original place is a directory. It must exists to be mounted. I’m not sure if we are talking past each other without understanding the point each person is trying to make.
As an example. Let’s say my system has an user with HOME set to /nas/user
As that user I wish to continue using that location. Moreover I wish to to use pathnames referring to files in my home directory when interacting with snap apps.
The problem is that from an app point of view /nas does not exist. The root filesystem is an immutable, read only core snap. To mount /nas/user as /nas/user inside the “container” I need to create /nas and then /nas/user but I cannot since EROFS.
There are some ways but we cannot use them at this time. Eventually we might be able to use the overlay filesystem but at present it needs more work in the kernel to work with confinement properly.
I see the debate above about allowing arbitrary home directories and the potential impact of that on the snap security model.
Is there any scope to allow for narrow individual exceptions, such as Fedora Silverblue’s use of /var/home in place of /home ?
Edit: It seems Silverblue in particular does ship with a symlink out of the box, linking /home to /var/home (the root FS is immutable and everything writable is mounted under /var).
Does the presence of this symlink make fixing the issue any easier?
I was directed here because sanp installs and snapd fail on my shiny new Ubuntu 20.04 (lasteest release).
For me and my industry experince this is a wrong turn. User facing function must always respect the user’s expressed intention in my book. This behaviour is equivalent to telling the user to make sure the compiled binary code is OK.
The semantics are straightforward: “/home/$USER/”, it is a regular Unix path name.
The flaw here lies in the over-reach to resolve perfectly legitimate human use file paths into machnine talk. When in truth use of the given (legitimate) path of “/home/$USER” will or should work in all cases. That is the design of the file system, symbolic links and mounts.
For comparison; I do not expect a compile error when the expression “i +=2;” isn’t written as “i = i+2;” And that is more or less what has happened here. A correct file path is rejected because of some internal scruples that have not bearing on usability or function.
If there’s a limitation in the stack, that needs to be fixed. So far I’ve found users are never the problem. Users want to DO something, technology’s role is to facilitate that something, not to put-up barriers. This is a very fundemental problem.
Software/Tooling must follow the user’s needs and wants.
that’s a good suggestion - I’ll add it to our troubleshooting page (Fix common issues), and add a link to that page from the installation page. Thanks!
an admin who is able to set up his users to use /home/DOMAIN should surely be able to also run the apparmor re-configuration for his users when making the other modifications to the standard install …
Hi, I tried the solutions provided here, bu still cannot make this work. My setup is as follows: I have multiple hosts (like a hundred, including cluster nodes), which have both local and remote users (taken from AD). Majority of the users (over 300) are the remote ones. The local users on given machine have home directory located in /home. For those snapd works perfectly. The remote users have the home directories located in /macierz/home which is mounted via NFS. Local users need to work at all times, they work perfectly with snapd. The remote users however cannot run snaps due to the permissions. The home directories cannot be easily moved to /home as they would overlap with the local users and people are already accustom to the homedir locations, multiple scripts also work based on that location. How can we use snaps with that setup? I really believe that this is a major problem and in distributed, multiuser environment you should be able to tell snapd where the home directories are.
Similar situation here. For enterprise use, it’s simply not feasible to have a Snap “confined” to home dir only; also, there’s this situation with different home directories (again, I live the same thing). I know that it’s difficult to setup AppArmor and other confinement techs to support all different scenarios, but some solution should be provided, if corporate use is, by any means, a goal of Snaps. Obviously, I’m talking about medium-sized+ companies; small ones might do just fine.
If AppArmor is the only thing blocking this, there should be a comprehensible doc telling how to reconfigure it. We could even have some config, like the ones in snap set system ....; something like snap set system homedirs, that could take a list of directories to be injected into AppArmor profiles; same thing for external directories, that could be injected into the profiles whenever they had home plug, but without dot files restriction, for instance. Well, just a shit storm, as we say here…
Fact is that this a much needed feature. I know manpower is not infinite, but maybe this could, at least, make its way into the roadmap, if it’s not.
