No "slot" exists that allows read-only access to any file

Bug #1609509 reported by Mike Pontillo
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
snapd
Confirmed
Wishlist
Unassigned

Bug Description

I want to snap a command-line utility that needs to be able to read a file, analyze it, and then print the results.

The 'home' slot isn't appropriate because it allows writing and locking files, which is too broad. It's also too restrictive since I want the snap to be able to read any file the user has access to, not just those in $HOME.

Revision history for this message
Gustavo Niemeyer (niemeyer) wrote :

That's an interesting problem to think through. We actually don't want to have an interface that has access to just any file without context, but I can see your use case for having some support for that ability.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

FYI, this also came up in the context of virus scanners.

tags: added: snapd-interface
Revision history for this message
Mike Pontillo (mpontillo) wrote :

For now, I would settle for a read-only 'home' interface to get it basically working. I don't want to allow writes.

That said, I think there is a strong use case for "read any file", too. What if I'm working with files in another user's $HOME? Or in /opt? Or /media? Or on a shared network drive? (I could continue.)

Restricting the snap to read non-hidden files in $HOME arbitrarily limits its usefulness.

Revision history for this message
Gustavo Niemeyer (niemeyer) wrote :

To be clear, I don't think that's a typical interface at all. It sounds like a different feature altogether. We don't want to have an interface like "read-any-file".

Revision history for this message
Mike Pontillo (mpontillo) wrote :

OK, I can certainly understand why that isn't generally desired. But there are plenty of use cases for snaps that should be allowed to read more than non-hidden files in $HOME. (What if I want to snap a SSH client, so I need the user's private key? Or an application that works with GPG keys?)

But for more general purpose utilities, why wouldn't you allow a permission like "read any file"? It's a legitimate need for some types of applications (dangerous or not). What if I'm snapping an data processing app and I want it to read arbitrary files on the system?

As for the alternative of a more granular 'home' interface, I have to ask: why just $HOME? Must I symlink from my $HOME to the places I actually want to be? Or do I have to copy things across filesystems to use them with snaps? It doesn't make sense to me. There should be a way for me to grant permission for a snap to access particular arbitrary files. Perhaps if one of the command-line arguments exactly matches a readable file, permission could be granted to the current process. Or I should be able to specify a list of allowed paths.

So a couple of user stories:

(1) As a user, I want to grant a snap permission to access certain files (either explicit, such as an access list, or implicit, such as by passing it to the snap on the command-line).

(2) As a developer, I want to specify a need to access certain files (such as ~/.ssh/*) so that my app can function properly.

The alternatives are ugly:
 - cat /media/usb/my-file | my-snap
 - grant 'network' privileges and ssh/scp/sftp/nfs/smb to the local host to grab arbitrary files (ouch)
 - grant 'system-trace' privileges and hack something together

Changed in snappy:
importance: Undecided → Wishlist
status: New → Confirmed
Michael Vogt (mvo)
affects: snappy → snapd
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.