So while i was testing my application hashit which is an command-line hashing application with some extended features, i found out that when trying to read from files in ‘strict’ was impossible because all IO-requests was to my snaps home dir, which is problem because then none of the files can be hashed.
Also the home-interface is not enough because then system-binaries from fx. /usr can not be accessed, so what i need is a way to read all files in a file system, and i also need write access for output, which can be simulated using ‘>’ but having your own argument ‘-o --output’ is convenient. So classic seems to be the best way to do all that.
Could we look at coming up with an interface that would let you read files without having to be classically confined? Perhaps (just a random idea) we could come up with an interface that prevents all IPC and network access but grants access to all the files?
Note that due to the way execution environment is formed you won’t have access to files in most places (even if apparmor is out of the way) because, for example /usr is remapped. If you want to you can teach your application to look at any path by prepending /var/lib/snapd/hostfs to it. This will give you the real content of that file but your snap needs to be aware of it (you can try it out in devmode while we figure out confinement).
Ok, for now i added the home plug and i am trying to work on a way so that i can use /var/lib/snapd/hostfs for the snap version, because i also have a pypi version which works just fine, and i don’t want two separate code-bases. Let me know when you got an answer. thanks!
Install your snap in devmode, it won’t work otherwise. Then run snap run --shell yoursnapname and go to /var/lib/snapd/hostfs (your snap cannot use classic confinement for this to work). You should see all the files on your disk now.
As a simple way to handle this with one codebase, simply see if SNAP is set in the process environment.
So, tried it again by installing it from snap it still doesn’t work, but if i pass it the --classic argument is does? so i migth need classic after all.
EDIT: It returns an Permission denied when trying to access /var/lib/snapd/hostfs so back to devmode
Yes, you need to stay in devmode but believe me that devmode is much, much better than classic. It’s an interface away whereas classic is executed in a totally different way so it works on fewer systems and it doesn’t run on core devices at all.
We could, but then that interface couldn’t be combined with other interfaces in a straighforward manner. It also doesn’t really help since two commands within the same snap could have different plugs (eg, cmd1 has this ‘backup’ interface and it copies everything to SNAP_COMMON, for cmd2 to send off).
You can also set your snap as a strict mode snap that plugs home and removable-media, etc so it will work for most people (if your application supported reading from stdin, it would work there too). Then you could tell people to pass --devmode when installing the snap to install in devmode and have access to everything.
I am already doing that, stdin, plugs and devmode. And so far everything is doing great other than that build.snapcraft.io is only builds for armhf which is a problem!
Ok, so it sounds like you are saying that you no longer are requesting classic confinement, so I’ll mark this as resolved. If this is in error, please let me know.
As for the build issue, I suggest creating a new topic so the right people will see it.
