At this point I just need to save data that is created by my app running as the user in such a way that a remove hook running as root in my app can access it.
My app needs access to data that my app created. This doesn’t seem to me like it should be some kind of security breach.
I feel like my app consists of a right hand (user code) and a left hand (root code), while brains that connect the two have to be installed separately.
It’s just very hard for me to believe that this is really the intent behind snapcraft. Apologies if I come across as a little irate. I’ve posted multiple threads over the past 2 months trying to figure out how to accomplish something realistic and workable and simple for the user, and every option I think of turns out to be a dead end.
One thing you can do is to use the home interface with the read: all attribute set. This adds policy which allows the root user to read non-root home directories, and it sounds like exactly what your snap needs to run properly. Try adding this to your snap:
If this works, you can request auto-connection of this in the #store category, as the home interface no longer auto-connects when you specify read: all.
Ah okay, I see what the problem is now. The home interface does not allow reading from $HOME/snap/... at all, with the exception of explicit white-lists of $SNAP_USER_DATA and $SNAP_USER_COMMON for that snap and for the current user the app is running as (so the normal app would be user myuser and the hook would be user root).
What should instead work is to put the files you care about in the home folder directly of the user, like in /home/myuser/my-app-config/file.txt. I have tested this and it works with the home read: all variant of the interface.
@jdstrand what do you think about extending the read: all variant of the home interface to allow also reading/writing by root of the $SNAP_USER_DATA and $SNAP_USER_COMMON directories for normal users? I’m not sure what the AppArmor would look like exactly, but perhaps it is doable.