Comment 43 for bug 1643706

> Wiadomość napisana przez Oliver <email address hidden> w dniu 04.05.2020, o godz. 09:39:
>
>
> @zyga wrote:
>
>> Allowing access outside of /home is possible but allowing access to arbitrary
>> places is not possible for obvious reasons. The work on portals is ongoing and
>> it will, for cooperating applications, allow to open files from user-specified
>> locations.
>
> The reasons don't seem so obvious to me. Could you please elaborate? I
> get it, confinement and all. But as a user I have no influence whether a

It's not just confinement. To understand the reason you need to build a mental model of how snap applications execute. The root filesystem is not writable. We cannot create arbitrary directories. The root filesystem is the current revision of whatever the "base" snap was picked by the snap developer, or in absence of any declaration, the core snap.

That snap as you may know, is an immutable filesystem image, pretty much like a CD-ROM image. Anything we "bring" from the host system, like the /home directory or the /root directory or /var/lib/snapd directory must *already* exist as an empty directory in the base snap. When we "bring" it from the host we create a mount point that shows a portion of the host filesystem inside the filesystem view that the snap applications see.

Let's say you want to put your stuff in /data, and you'd like to have a configuration file that makes that directory visible for snaps. To do this you have to solve all of those challenges:

 - how to create /data so that you can mount (host)/data into (snap)/data?
 - how to represent /data for security, is it equivalent to the home interface or do you want to special-case it?
 - what if the location is not /data but actually something that already exists in snap view? say /usr/lib, after all, it is configurable so the user may, without knowing the consequences, choose to do that.

> snap comes as strictly confined or not. And so when facing this issue I
> am looking to _configure_ this in a way that makes it possible. Why
> can't the user (or admin) decide on their own? For example in my case

Because to make the system possible at all (i.e. programs execute) we decided that some conventions are sufficient and any data management problem can be framed in the established conventions. Anything you choose to store in /data or /foo or wherever *may* be represented as a directory in your home directory in /home/$LOGNAME. Is it annoying if you were using /data for years? no doubt. But it is possible. We have not found a way that would let us do anything else while keeping snaps executable.

> I'd want to add /data/oliver to the list of locations that are available
> to this particular snap (vlc) and I may want to make _other_ locations
> available to other snaps. Sure, there will probably be users who'd give
> some of their snaps free rein, but shouldn't that be their prerogative?

It's not a matter of choice but of implementation. I strongly invite you to join us on #snappy on freenode and discuss implementation. If you come up with a way to make it work I would love to help you implement it.

>
> I'll even take it further: when I would connect _my_ particular
> "arbitrary" location to the vlc snap I'd want to do that read-only. I
> see no reason for VLC to do more than reading in those locations. This
> may vary for others (e.g. to be able to create playlists or so?!), but
> I'd simply want my outside location to appear inside the snap read-only.
>
> Just since @chipaca was trying to elicit use cases ;)

The implementation is evolving. As we gain more kernel features and learn of creative ways to use existing features it may become possible to do what you want. Right now we are where we are.

I hope you understand where we are coming from. There are lots of use cases and everyone cannot be supported at the same instant in equal amount, as we have finite resources.

Best regards
ZK