[I hope I’m using the right terms.]
I want password manager app A to provide plugs “A:mydatabase” and “A:attachments”. It would use “A:mydatabase” to read/write the password manager database, and “A:attachments” when importing or exporting attachment files (e.g. JPGs) into/outof the database.
I don’t want to give app A full access to anywhere under my home directory.
Instead of connecting slot “:home” to each of these plugs (probably not even possible, because names have to match), I want slots that specify individual directories or files, or a list of directories or files. So maybe “A:mydatabase” would connect to “:files123” (which maps to “~/secrets/mypwdatabasefile.db”), and “A:attachments” would connect to “:files345” (which maps to “~/Downloads/,~/Documents/”) in my system. In another system, the admin could choose different “:files” slots, or “:home”. The admin could create and modify as many “:files” slots as they wish, define them in any way.
This is not supported today, right ? There is no equivalent of the “:files” slot or interface provider, the password manager app is not free to create its own arbitrary plug names, and for a connection the plug and slot names have to match.
Is it possible to support this in the future ? Thanks.
A Snap package may use whatever names it wants for a plug or slot, within the rules of no spaces or special characters like % and *.
The plug and slot names do not need to match to be connectable. They merely need to use the same interface.
Your password manager will be able to save files in its own location at ~/snap/A/common and ~/snap/A/current - respectively exposed as $SNAP_USER_COMMON and $SNAP_USER_DATA.
Conceivably you could use the personal-files interface for the password manager Snap, but you need to rebuild the Snap to add this. The caveat is the personal-files interface is not freely available - you need to request the usage and provide reasoned argument why your Snap has ownership of the paths you’re requesting access to and usually the responses are to only allow read-only access, not writable access.
Okay, I was reading “A slot and a plug can only be connected if they have the same interface name.” from https://snapcraft.io/docs/interface-management
So it’s not limited to the names listed in https://snapcraft.io/docs/supported-interfaces ?
Maybe I’m confused between interface name and plug/slot name ? Is “:home” an interface name or a plug/slot name ?
So personal-files is the only way to let the user choose directories ? An app can’t just say “I have 4 types of files, I want to let the user specify 4 different places to look for them” ? I want to put control in the hands of the user/sysadmin.
I think the right way to do what you are after is using content interfaces. You snap with these secrets and attachments saves it’s files wherever it wants into ~/snap/A/common or ~/snap/A/current, and then sets up content interface slots like so:
slots:
secrets:
interface: content
read: $SNAP_USER_DATA/secrets
attachments:
interface: content
read: $SNAP_USER_DATA/attachments
and then the snap wanting to use these things does:
plugs:
attachments:
interface: content
target: $SNAP_USER_DATA/attachments
and similarly if you had a snap C that wants/needs to access secrets would use a similar plug but for secrets. After installing both snaps you then do:
snap connect B:attachments A:attachments
and now snap B can only access the files that snap A puts into it’s $SNAP_USER_DATA/attachments folder, not the $SNAP_USER_DATA/secrets folder
I am trying to get to a situation where the user/sysadmin is in control of the locations. I don’t want to force the files to be under ~/snap/APPNAME.
Is your application a graphical one? If so then maybe you could use portals instead?
To be clear, even if you went with the personal-files interface usage as mentioned above, the location would be hard-coded into the interface plug definition.
What is consuming the files? Will it always be other snaps?
I’m not the app developer. I’m trying to explore how I can sandbox all of the apps I can use.
No, I don’t want the file location hard-coded into anything. User should be able to set it.
Please tell me snaps will not be using portals. I just went around the block with the Flatpak guys about portals. User uses Flatseal to set all kinds of nice permissions to restrict the app, then file-open dialog is done by a portal which is UNRESTRICTED. Totally violates all the permission rules, and supposedly that’s okay. Please tell me snaps won’t behave the same way. Please.
I’m slightly confused by this, the portal does not run in the sandbox of the app, the portal runs outside of the app sandboxing so even if the user could pick any file through the portal, the sandboxed snap can only access that file if the user uses the portal to do so. In other words, the sandboxed app is not permitted to access any file - only files the user allows through the portal.
Well our desire is generally to see more and more snaps use portals because they provide the best of both worlds for not allowing arbitrary file access to snaps, but still allowing an end-user to provide specific access to files the user chooses.
This is related to this conversation: Classic confinement for wal-g. Today there isn’t a mechanism for the user/sysadmin to control the locations arbitrarily. The snap could provide some choices to the user/admin though. As seen in the other thread, there is ongoing work to enable features like this (and more).
Nooooo !!! Don’t do it !!!
I just went around in circles with the Flatpak guys about this. Portals are creating a bifurcated, non-standard permission situation, and changing the semantics of an existing UI construct (file-chooser dialog). What is the point of setting permissions on a container image if the user clicking Open or Save button in a dialog simply overrides all the permission settings ? This is completely wrong.
They seem to have the view that now an app will have two kinds of actions: one that comes from “the app itself” and is controlled by permissions, and another that comes from the user’s button-push and implicitly overrides all container permissions.
This behavior is surprising and will lead to all kinds of confusion and redefines the meaning of standard UI constructs. Please don’t do it !
Portals put the user in control of their own system. When an application opens the file-picker dialog it does so via signalling the portals dbus service which then displays the file picker outside of confinement. This allows the user to browse any files and folders on their system without exposing those files and folders through the confinement to the application. Once the user makes their selection and submits the dialog the portals daemon will make the file accessible via copying it into a location that the application can view and will copy the file back again once the application has closed the file probably after making changes. At no point in time is the application aware of where the file is located or anything else about the system when using the portals api.
No, portals are a dodge used because the container permission design is not rich enough. A user/sysadmin can’t specify file/dir permissions in the container permission systems, so let’s silently give permission by virtue of the user clicking the normal Open or Save button in the normal file-chooser dialog.
Fix the permission structure, don’t silently override the whole thing by redefining the meaning of a standard UI construct.
Are portals also going to do this for non-container apps ? Why not ? Why shouldn’t clicking Open in the file-chooser dialog override chmod settings of the file ? Should the user be allowed to override chroot settings ? Why not ? Put the user in control ! Why bother them with silly permission rules ?
