snap apps need to be able to browse outside of user $HOME dir. for Desktop installs

[Doug McMahon]

Otherwise in many cases the app is semi worthless.
Ex.
Install vlc snap, open vlc
Try to open a file that's not in your home folder, can't do so thru the open file browser.
Same for krita - can only open files in user home or /snap/krita.

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: snapd 2.17.1+17.04ubuntu1
ProcVersionSignature: Ubuntu 4.9.0-1.2-generic 4.9.0-rc5
Uname: Linux 4.9.0-1-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Nov 21 16:38:19 2016
InstallationDate: Installed on 2016-11-09 (12 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Alpha amd64 (20161106)
SourcePackage: snapd
UpgradeStatus: No upgrade log present (probably fresh install)

[Sebastien Bacher (seb128)]

Thank you for your bug report, the confinement restriction is a feature though. Where do you want to play videos from? Reading from another location than your userdir or removable media or remote shares is probably something most user never do...

[Doug McMahon (mc3man)]

I don't believe it's atypical for users to have & use a data partition or want to access files from mounted removable media.
I guess this would somewhat be mitigated if snaps showed up in the file browser's context menu by default (- rather than users needing to create a local .desktop for that.

[Jamie Strandboge (jdstrand)]

FYI, the apparmor rule for browsing any directory is:

   /{,**/} r,

Also note that there is now a 'removable-media' interface that vlc, et al can use to be able to access /media/....

There is definitely a usability issue though because Seb is right-- it is a core feature of strict confinement that snaps cannot see other snaps, files, etc, but file choosers need to be able to do so and adding a rule like the one above breaks that. Adding another transitional interface to allow filesystem browsing and/or adjust home is possible....

The best long term answer is perhaps for the file chooser to run out of process from the snap so that the chooser can give the snap what the user selected and the snap doesn't need any extra privileges. This is in part what the content-hub on Ubuntu Touch and Personal is designed for. For general purpose use, this technique requires help from the system (ie, the privileged file chooser service, which could be a slot implementation snap), an interface to use the service and for the snap to plugs that interface and actually use the service (either it is changed to do so or the popular toolkits are updated to do it behind the scenes).

Fixing this bug requires design. Gustavo, do you have thoughts?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[ventrical (dale-f-beaudoin)]

It is just as bad (if not worse) in unity8.. but I think a different bug needs to be filed with other breakage.

[Doug McMahon (mc3man)]

I was wrong about the context menu, apps would still be confined. As it stands this will just lead to widespread advice to install apps with --devmode.
(- or if that's the only way then maybe some snaps should default to devmode & users can disable that if they wish..

[Michael Vogt (mvo)]

The new "classic" confinement will fix this.

[Jamie Strandboge (jdstrand)]

@Michael and @Zygmunt -- classic confinement won't fix this, it will only workaround it. This bug is about a 'confinement: strict' snap (vlc) that works completely fine with strict mode except for being able to browse outside of the directories that the snap is configured to use (ie, outside of home).

[Strangiato Xanadu (strangiato)]

I cant play videos from my ntfs partition using vlc player. I get "access denied" error.
Fix this absurd problem please.

[hackel (hackel)]

I just installed the snap version of VLC for the first time, and the very first thing I did was try to play a video from my (NFS mounted) media server. No-go. Is there some rule that all remote shares must be mounted under /media now? (vs. /mnt which is what I've always used) This at the very least needs to be better documented. Extremely poor user experience. Snap apps continue to be nothing but a huge pain in the neck.

[Ben (bhjolly)]

Same problem with cloudcompare. Installed using snap, launches fine, can't find any files as I don't keep gigantic 3D point clouds in my home directory. Seriously, what is the point of this thing?

[Jamie Strandboge (jdstrand)]

Responding to myself:

"There is definitely a usability issue though because Seb is right-- it is a core feature of strict confinement that snaps cannot see other snaps, files, etc, but file choosers need to be able to do so and adding a rule like the one above breaks that. Adding another transitional interface to allow filesystem browsing and/or adjust home is possible...."

FYI, the removable-media interface has allowed reading dirs for /run, /run/media and /media while the default template has allowed reading /home/ and / since 2.29 (see https://forum.snapcraft.io/t/application-cant-see-media-in-file-browser/2384/9). This means that vlc, etc can navigate from $HOME -> /home -> / -> /media -> ... without any usability issues.

In 2.31 we adjusted the transitional home interface to allow reading ~/snaps. Since snaps start in $SNAP_USER_DATA (~/snap/<name>/<revision>), this means that a snap can navigate from $HOME/snap/<name>/<revision> -> $HOME/snap/<name> -> $HOME/snap -> $HOME.

Between these two items, traditional file choosers should now operate without usability issues. Which is this bug. As such, marking as Fix Released.

[Jamie Strandboge (jdstrand)]

@hackel and @bhjolly - yes, there are limitations in what strict confinement allows. We have transitional interfaces for home and removable-media that allow snaps to access the user's files and hotplugged media. If you mount outside of these areas, snaps will not be able to access the data. Today you can workaround this be choosing a mountpoint under /media or bind mounting into it.

Very soon snapd will be able to leverage portals for arbitrary file system access (this will hopefully be in 2.32). The major toolkits like gtk3 and qt5 should then 'just work' and use the portals file chooser instead of falling back to the traditional file chooser.

[Doug McMahon (mc3man)]

Looking at vlc as an example in 18.04 things seem much better & also appears accessible folders that shouldn't be has been cleaned up a bit.
Do wonder why vlc can still access /dev & /lib, not that there are any media files there but seems odd it can..

[Jamie Strandboge (jdstrand)]

/lib is allowed via the AppArmor base abstraction and /dev directory reads is allowed as a convenience (apparmor and device cgroups mediate device access).

[Peter Valdemar Mørch (pmorch)]

@jdstrand: You write:

> Very soon snapd will be able to leverage portals for arbitrary file system access
> (this will hopefully be in 2.32).

I see that I'm using snapd version 2.32.5+18.04 here in Xubuntu 18.04.

Should I now somehow be able to use "portals" to access files in my NFS mount in /store ?

I like '/store' for my NFS mount. I don't want it to be /home/peter/store or /media/store or anything else than /store.

But I don't see any way to allow snaps access to /store.

Is that really are hard and unconfigurable limitation to snaps that they can access files *ONLY* in /home/<user> and /media? Really?

[Peter Valdemar Mørch (pmorch)]

I'm wondering why this bug has been marked as "Fix Released". :

The title says: snap apps need to be able to browse outside of user $HOME dir
And the body of the first post says: Try to open a file that's not in your home folder, can't do so thru the open file browser.

Isn't that still true even with 2.32 in Ubuntu 18.04?

[Zygmunt Krynicki (zyga)]

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.

Jamie marked is as Fix Released with precise description of what is allowed. The rest of the work will involve portal integration and it will be released to 18.04 and 16.04 (most likely) and available in most recent versions of other distributions.

[Peter Valdemar Mørch (pmorch)]

Thank you @zyga for your reply.

I think I understand it. I'll sit tight and await the portals integration to finish and make it to 18.04. Then I'll be able to configure snapd to allow vlc to open files under /store (perhaps requiring a patch to vlc to enable the portals cooperation).

[CarbonPepper (carbonpepper)]

Still looks like a bug not a feature. If it were a feature, it would have the necessary communications with the end user sorted out completely. I wasn't even aware of this crucifying limitation until I saw an error on 18.04 via hugo:

client1:/media/web_server/hugo$ hugo new site hugotest
Error: Failed to create dir: mkdir /var/lib/snapd/void/hugotest: permission denied

If it were a feature, then snap itself would say something about snap app can't write outside of your home directory.

As far as a feature goes, it precludes any user with a NAS or any kind of network share. It's too dumbed-down to be of use.

[John Lenton (chipaca)]

@abssorb The hugo snap seems to be missing the 'removable-media' interface that'd let you use it with /media. I'd say that's a bug in the hugo snap.

And you're right, communicating of why something isn't allowed is not properly done yet. It's hard. We'll get to it, hopefully, someday. But that's not what this bug is about.

[Nato Boram (nato-boram)]

What about snaps that operate as a command line and an environment variable? I set IPFS_PATH to /mnt/Shared/IPFS, but IPFS outputs a "permission denied".

[Oliver Grawert (ogra)]

the /mnt dir (and all subdirs underneath) is also covered by the removable-media interface that was mentioned above (in the most recent snapd versions).

[Nidal R (nidalr)]

VLC is a media player... Kind of like a text editor, Opening files from arbritary locations is well within expected usage... At minimum, Snap should allow users to open arbritary files via the open dialog. Or maybe vlc should not be installed as a confined app..

[Nidal R (nidalr)]

Okay, i tried open the file after re-installing vlc via --classic, still no dice... wth?

[Peter Valdemar Mørch (pmorch)]

There is also this related/identical question on askubuntu:

How to give snaps access to /somedir
https://askubuntu.com/q/1033344/34154

[costinel (costinel)]

>Sebastien Bacher (seb128) wrote on 2016-11-22: #2
>
>Thank you for your bug report, the confinement restriction is a feature though. Where do you want to play videos from? Reading from another location than your userdir or removable media or remote shares is probably something most user never do...

**anywhere**

I want to browse the full filesystem to play media from literally anywhere

Now, I do understand the snaps were invented for a slightly different purpose than using snap vlc as the main video player, but some of us do.

Is there any easy quick workaround to enable a snap package to browse unrestricted the whole root filesystem and any other mounted filesystems?

[Hans Deragon (deragon)]

Got my files in a common mount point /vol/media where all members of the family have access too (we share the same computer). No one should have to make a local copy of a family video in their respective /home directory to look at it. And it is a bit ridiculous that now, going forward, every mount points, including those that our on non-removable media, should be done in /media to get things to work.

There are also businesses/schools that have mount points elsewhere, network mounts, hard coded at one location, on system where users do not have root access.

And if you make use of the 'mount bind' workaround, then you hit the problem of file transfers and Trash not working anymore. Damn if you do, damn if you do not.

Please introduce a configuration file. It is easy to implement, and leave us, users/administrators to decide to move away from the current default.

Mount bind issue: https://unix.stackexchange.com/questions/406351/mount-bind-in-the-same-filesystem-move-files-as-in-the-same-filesystem

[Stéphane Gourichon (stephane-gourichon-lpad)]

Today, after very poor past experience with snaps, I thought to give it a go once again to use some third party software packaged as snap.

Alas, I see this bug is sadly still not fixed.

# Docker (arguably different use cases) got it right

With docker it can be as easy as:

    docker run -it -v $PWD:/somemountpoint myprogram myarguments

and voilà, the docker-confined app sees your current directory as /somemountpoint.

# Snap as policy and communication failure

The current snap experience is: users run software, perform reasonable actions, see cryptic failures, ask reasonable "howto" questions and get "no reasonable person would do such action" answers.

I respectfully disagree.

IMHO no reasonable software provider should treat they users like that.

Such rejection attitude to users maintains the status quo and overall saps snap reputation.

[Zygmunt Krynicki (zyga)]

Hey

snapd developer here. I've been working on a feature that would greatly improve the user experience of accessing arbitrary files. The problem with the feature is that it is still in early stages, both userspace and kernel, so we cannot rely or ship it.

I want to re-assure you that this is being worked on and our goal is to make it possible to just work, like people were used to.

[Peter Valdemar Mørch (pmorch)]

Hi Zygmunt,

Thanks for your comment.

Just so I understand... Will this new feature allow me to configure vlc so that "vlc /my/custom/path/file.avi" will be possible? If so, that would be grand!

[Zygmunt Krynicki (zyga)]

When the feature is available you will be able to open any file and just confirm a prompt using a trusted security mechanism (e.g. integrated with gnome shell). All files are representable from a snap point of view, though not at the original path (in your example the path will be /var/lib/snapd/hostfs/my/custom/path/file.avi, though we are also considering abbreviating that to /host/my/custom/path/file.avi

[Doug McMahon (mc3man)]

That sounds interesting.
The snap I'd test on is the snap gedit which currently borders on useless
except for local non hidden files & same on removable media.

On Sat, Feb 8, 2020, 12:01 PM Zygmunt Krynicki <
<email address hidden>> wrote:

> When the feature is available you will be able to open any file and just
> confirm a prompt using a trusted security mechanism (e.g. integrated
> with gnome shell). All files are representable from a snap point of
> view, though not at the original path (in your example the path will be
> /var/lib/snapd/hostfs/my/custom/path/file.avi, though we are also
> considering abbreviating that to /host/my/custom/path/file.avi
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1643706
>
> Title:
> snap apps need to be able to browse outside of user $HOME dir. for
> Desktop installs
>
> Status in snapd package in Ubuntu:
> Fix Released
>
> Bug description:
> Otherwise in many cases the app is semi worthless.
> Ex.
> Install vlc snap, open vlc
> Try to open a file that's not in your home folder, can't do so thru the
> open file browser.
> Same for krita - can only open files in user home or /snap/krita.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.04
> Package: snapd 2.17.1+17.04ubuntu1
> ProcVersionSignature: Ubuntu 4.9.0-1.2-generic 4.9.0-rc5
> Uname: Linux 4.9.0-1-generic x86_64
> ApportVersion: 2.20.3-0ubuntu8
> Architecture: amd64
> CurrentDesktop: Unity
> Date: Mon Nov 21 16:38:19 2016
> InstallationDate: Installed on 2016-11-09 (12 days ago)
> InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Alpha amd64 (20161106)
> SourcePackage: snapd
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706/+subscriptions
>

[Peter Valdemar Mørch (pmorch)]

> and just confirm a prompt using a trusted security mechanism (e.g. integrated with gnome shell)

Oh, no, I'm glad I asked...

So what whould then happen when vlc automatically tries to open the subtitle file associated with the video? When I open "vlc /my/custom/path/file.avi" I presumably will get a dialog box (because lets be specific: that is what I'll get, right?) will I then also get another dialog box when vlc tries to open "/my/custom/path/file.srt" 1 ms later?

Just to be clear: I would *much* prefer to *configure* vlc to be allowed to open everything under /my/custom/path/ without any extra confirmation. Especially because if there is "a trusted security mechanism (e.g. integrated with gnome shell)" there is no way for me to use snap apps in scripts, e.g. if they have options that allow them to perform bulk operations.

[John Lenton (chipaca)]

First, to be clear, the best way forward for integration is via desktop portals, where the access and authorization is integrated into the desktop shell. I don't know the status of that work but it's ongoing.

The work Zyga is prototyping is to allow non-desktop-integrated snaps (like, indeed, vlc, or hopefully even server snaps on a headless system) to have a similar mechanism, perhaps less smooth but still usable.

As I understand it Zyga's work is exploratory in nature, to see what's possible, before sitting down with designers to discuss what we want to do with those possibilities. Given this, I think it's a little early for getting upset about a UX you're imaging to be bad before it's even discussed, let alone implemented.

It is, however, a good time for describing how you'd _like_ to use something like this.
Just don't let it go all "Oh no! You're ruining my workflow!" or whatever. Document use cases, etc.

Keep it civil.

[Peter Valdemar Mørch (pmorch)]

Hi John,

I've outlined my use case here:

How to give snaps access to /somedir - Ask Ubuntu
https://askubuntu.com/questions/1033344/how-to-give-snaps-access-to-somedir

I want to access my files in /somedir. I don't want snaps to dictate '/home', '/mnt' or any other special directories. It is fine that these are the defaults _as long as I can change these directories in a configuration file_.

vlc /somedir/video.avi

should start the video including any /somedir/video.srt subtitles if present, just like a standard client does without any additional interaction from me.

Is there better documentation on what "deskop portals" are than https://flatpak.github.io/xdg-desktop-portal/portal-docs.html?

That links says:

> Requests made via portal interfaces generally involve user interaction.

That means a dialog box, right? Will it be possible to configure "portals" somehow so that vlc subsequently can access /somedir recursively _without_ me, the user, noticing? Because them I'm happy! :-)

In the https://askubuntu.com/questions/1033344/how-to-give-snaps-access-to-somedir link above, Zygmunt says:

> There's no way to do that that is general, safe and sound.
> I know everyone loves to customise their filesystem but that
> has some cost and this is one of them."

I beg to differ. If course it is possible to do that in a way that is general, safe and sound. Perhaps it goes against the current design of snapd. Perhaps (e.g. for that reason) this project chooses not to do it - ever. But to say it isn't possible is simply not true. (Docker can do it, apache2 and many other apps can do it).

So would it be possible for you guys to outline how it will work once the Portals integration and/or Zyga's project works?

* Will I be able to add custom directories to the list of already-trusted directories?
* Will I be met with additional dialogs when I type vlc /somedir/video.avi? How many, given that vlc searches for a tries to open .srt files too?
* Will the same be true if I double-click on file.avi from e.g. xfce's thunar file manager?

Being met with additional dialog boxes to confirm that I want to open a file in /somedir (and then again when accessing the .srt file?), may be fine for others, but does not constitute the user experience I'm looking for. Sure, it is better, but not good enough for my use case (a NAS mounted on /somedir). I'll be annoyed with it every single time I use it.

If you yourself had 99% of your videos under /somedir, would you yourself be happy with having to confirm something every time you wanted to open vlc /somedir/video.avi?

In this thread I thought that finally it was going to be possible. If you decide not to cater to my use case, that is fine, it is your project. But then please just say so explicitly, so I'll *know* that snapd will never be for me so I can choose something else and not wait for portals or whatever other developments that don't solve my use case anyway.

[Peter Valdemar Mørch (pmorch)]

Stéphane Gourichon says it much better in fewer words than I've been able to in https://askubuntu.com/a/1040278/34154:

> @ZygmuntKrynicki Thanks for popping in and explaining that the code does what you intend. I respectfully and totally disagree with what you write. Hard-coding paths is very poor practice and cannot be meaningfully justified, even in the name of security. It's just basic inflexibility.

[Peter Valdemar Mørch (pmorch)]

John writes:
> The work Zyga is prototyping is to allow non-desktop-integrated
> snaps (like, indeed, vlc, or hopefully even server snaps on a
> headless system)

Sorry I missed that. I interpret that as meaning vlc won't be supported/affected by Portals integration even when it is done. :-(

So either vlc has to support Portals (whatever that means), or the work Zygmunt is prototyping is the only hope we have of allowing access to arbitrary files.

Zygmunt wrote:

> I want to re-assure you that this is being worked on and our goal is to make it
> possible to just work, like people were used to.

I like the sound of that. But if it involves having to accept a additional dialogs, then that is not what this person was used to.

Ok, I think I've been clear. I'll shut up for now.

[Ebuzer Taha Kanat (ebuzer)]

For
snap 2.44.3
snapd 2.44.3
series 16
ubuntu 16.04
kernel 4.15.0-15-generic

even when
home gedit:home :home -
connected

gedit snap can't acces to file in $HOME/snap/chromium/current/Downloads/

It can access to everywhere under $HOME but $HOME/snap/

It warns "You do not have the permissions necessary to open the file."

[Doug McMahon (mc3man)]

Your wasting your time commenting here about that near useless gedit snap.
This bug is fix released, no one pays attention, I'm removing notifications
myself now.
File a bug, preface description with [Snap], don't hold your breath..

On Sat, Apr 25, 2020, 1:20 AM Ebuzer Taha Kanat <email address hidden>
wrote:

> For
> snap 2.44.3
> snapd 2.44.3
> series 16
> ubuntu 16.04
> kernel 4.15.0-15-generic
>
> even when
> home gedit:home :home
> -
> connected
>
> gedit snap can't acces to file in $HOME/snap/chromium/current/Downloads/
>
> It can access to everywhere under $HOME but $HOME/snap/
>
> It warns "You do not have the permissions necessary to open the file."
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1643706
>
> Title:
> snap apps need to be able to browse outside of user $HOME dir. for
> Desktop installs
>
> Status in snapd package in Ubuntu:
> Fix Released
>
> Bug description:
> Otherwise in many cases the app is semi worthless.
> Ex.
> Install vlc snap, open vlc
> Try to open a file that's not in your home folder, can't do so thru the
> open file browser.
> Same for krita - can only open files in user home or /snap/krita.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.04
> Package: snapd 2.17.1+17.04ubuntu1
> ProcVersionSignature: Ubuntu 4.9.0-1.2-generic 4.9.0-rc5
> Uname: Linux 4.9.0-1-generic x86_64
> ApportVersion: 2.20.3-0ubuntu8
> Architecture: amd64
> CurrentDesktop: Unity
> Date: Mon Nov 21 16:38:19 2016
> InstallationDate: Installed on 2016-11-09 (12 days ago)
> InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Alpha amd64 (20161106)
> SourcePackage: snapd
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706/+subscriptions
>

[Oliver (oliver-assarbad)]

Regarding use cases, I am mostly with @pmorch.

What I _thought_ when I dug into the documentation a bit was that the connections would lend themselves to the purpose (snap connections vlc). But it turns out that the list of those are predefined and so I am not able to "wire" a given snap in a way that it can access a separate location.

/home and /mnt are conventions, true. But should users be _bound_ by those conventions? It appears that LSB/hier(7) are there for _distributors_ in the widest sense, not to limit the _users_ in what they can do.

@jdstrand wrote:

> Also note that there is now a 'removable-media' interface that vlc, et al
> can use to be able to access /media/....

Why not have something like removable-media but where a user can set a per-system or even per-snap configuration what comprises that particular set of paths?!

Would this require a grand redesign?

@strangiato wrote:

> I cant play videos from my ntfs partition using vlc player. I get "access
> denied" error.

Isn't that an entirely different issue, though? When I encounter the issue described in this ticket, I receive:

  Your input can't be opened:
  VLC is unable to open the MRL 'file:///...'. Check the log for details.

@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 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 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?

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 ;)

@nidalrashid wrote:

> Okay, i tried open the file after re-installing vlc via --classic, still
> no dice... wth?

In my case I got a message that told me that --classic is ignored for strictly confined snaps.

@deragon wrote:

> Please introduce a configuration file. It is easy to implement, and leave
> us, users/administrators to decide to move away from the current default.

I wholeheartedly agree with this sentiment.

Alternatively LXD seems to be able to make a path from the host appear in the guests's namespace. Since snaps use namespaces, would that not be also an option?

https://ubuntu.com/blog/mounting-your-home-directory-in-lxd

Thanks,

Oliv...

[Zygmunt Krynicki (zyga)]

> 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_...

[Oliver (oliver-assarbad)]

Dziękuję! Your insights are very much appreciated. I learned something new.

> - how to represent /data for security, is it equivalent to the home
> interface or do you want to special-case it?

I'd like to _assign_ it to some predefined interface at least. Special cases tend to make things more complex which usually doesn't help security.

> - 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.

Hmm, aren't developers allowed to limit the number of choices a user has, though? So what's the trouble in failing to mount a snap which has such clashes? Personally I'd write _that_ off under "fail early" and be very happy with it as a user. At least this way _snap_ would show a clear error rather than VLC showing some error which doesn't make sense at face value.

And this way it's likely I would have caused issues anyway (i.e. by specifying an illicit path that was already present in the snap), so by the system preventing me from doing it, no harm would have been done, right? And it's better than figuring out some time later that something fails, just because the VLC running as a snap doesn't have the same idea of the file system I have (which is by purpose, I understand, but which isn't obvious without some additional reading -> user perspective).

So long story short: the ease of use that the snap packages supposedly bring, falls apart quite quickly if you run into an issue like _this_.

And seeing it without knowing implementation details (like you!), the VLC instance has presumably no idea that it's running in as a snap and possibly shouldn't know it either, whereas as a user I am left to assume that VLC is to blame (which, it turns out, it isn't).

Hope that clarifies a bit better why I think this is a usability/UX issue.

With the --classic option not working, but being touted everywhere as a "workaround" for the issue and with VLC fully moving to snaps, where does that leave me as a user?

I get that there ought to be a balancing between security and convenience. But convenience comes in shades, whereas the refusal of VLC to play stuff is binary (either it plays or it refuses to play outside of hardcoded locations ... but with an error message that doesn't _really_ help me as a user; and I had looked into snaps before due to LXD).

> 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.

Yep, I'm an avid user of bind-mounts already, so it's not a huge deal for me. However, some tools do misbehave with bind-mounts, so items show up multiple times in GNOME despite x-gvfs-hide mount option. And _that_ - while not to be blamed on snap or VLC - is an issue that means that there are now already two aspects that force me to adjust the way I work.

> 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.

Absolutely. I have the same ...

[Nigel Stewart (nigels)]

This situation is absurd.

All my music and videos are on a NAS.
They are not mounted in /media for good reason.
Is there a setting? No? Epic fail.

[Zygmunt Krynicki (zyga)]

@nigels - there is no setting because there's no real way to represent arbitrary location. This is a very hard technical problem, not the lack of a knob to control some setting.

There are conventions we could use to get to a state where most users could be happy. Where is your music and videos mounted? Could you mount them in a sub-directory of /mnt perhaps?

[Bogdan Mart (winnie-ua)]

Have same issue with Telegram snap app.

I have file inside /tmp dir (I do not won't to polute system with files downloaded so basically /tmp is my browsers download dir) and I want to send to my peers using instant messenger, but Telgram can't access /tmp

[Rajat Pandita (rajat-pandita)]

I have my Secondary Disk mounted under /Data and I have videos and music in the directory. none of my installed snaps can see this directory no matter what. I think this bug should not be marked as fix released.

[Zygmunt Krynicki (zyga)]

Dear Rajat, please mount your external disk under /mnt/* or using dynamic location in /media. Those locations are not supported. Arbitrary locations cannot be supported, until all applications access files using portals.

[Oliver (oliver-assarbad)]

Hi Zygmunt, I can only surmise what the statement by Rajat may have meant, but indeed any status calling this "fixed" seems somewhat _odd_. But on the other hand there is little reason to change it now after two and a half years.

Any idea where to find more information about the progress on portals, Zygmunt?

Thanks and with best regards,

Oliver

PS @winnie-ua bind-mounting worked for me. Together with udisks2 and systemd you can also make this available on-demand for unprivileged users to some extent.

[Patrick Dinklage (pdinklag)]

At our university, we use a network-mounted /home directory, but it is inherently slow. Every employee is advised to store data that doesn't have to be shared among all systems in their local /scratch directory structure on that machine (desktops, practically), which is backed up regularly. So there you have a perfectly valid reason for using neither /home nor /media.

I'm speaking from an end user perspective, and it's completely inconceivable that I cannot access arbitrary files on my system. I have a snap application where I can hit "File > Open" in the menu, and the dialogue displays my Ubuntu shortcuts. All of them point to locations somewhere in /scratch. When I click on them, they don't open, and I had all kinds of suspicions but this. So really, from a user perspective, this is most definitely a bug.

Using symbolic links doens't work, and since I don't have root access to the machine, I cannot simply re-mount devices. Is there any way to work around this until the fix actually reaches users (Ubuntu 18.04, again with no choice over the OS version)?

[christian.comes (christian-comes)]

British style comment:
it is inconvenient that snaps behave this way, from the point of view of the user.

Real meaning:
I just cannot understand how a *single* developer may even think that this snap behaviour is acceptable in any way- it is a show stopper, i.e. a reason to fire a full department of developers, to just remove snap fully from Ubuntu.
I had to remove chromium because it is a snap and it just does not access my folders. I have to use old versions of apps that behave the same unacceptable way.
I cannot imagine why this is even a discussion and not the #1 working item on the table of the developers of snap.
You discuss about different mount positions and the likes- sorry, that is why linux has a strong permissions system and strong filesystems. Let that work! If you sandbox snaps that much, then please stop providing most apps via snaps.
the current status is just unacceptable.

[Matthew Guay (matt-d-guay)]

Just chiming in to say I am having the same problem with a snap (Tiled), neither the --classic workaround nor sudo snap connect tiled:removable-media works. Between this and the other issues people have noted with snap, it seems like it is just bad software and the team is not doing a good job creating something valuable for the end user.

[Oliver (oliver-assarbad)]

I'll be the first to concede software issues aren't god-given (they're developer-given ... or imposed); being a developer this is something I basically preach to fellow developers. But a blanket statement of "it is just bad software" seems a bit over the top. I think snaps do indeed provide added value.

While I bemoan the fact that it's Canonical-driven, it _does_ add host-guest-separation. Both in the security sense and in regards to libraries within and without. It's just that this separation is working a little too well for a lot of real-world scenarios, it seems.

To me the problem appears to be more along the lines of either adoption going faster than anticipated [1] and so development resources becoming a bottleneck, initial planning missing certain use cases (see above) or issues that arose from the combination of the two.

So despite all criticism I uttered before (see above) I want to state that _I_ do not consider snapd bad software!

[1] VLC would be a prime example of that. While obviously it could benefit from the added security (decoding file formats has long been a favorite target for exploits), the fact that I can't browse just anywhere means that packaging it as a snap may just be picking the wrong tool for the desired job. So works nice for Wekan, but for VLC not so much ...

[FelipeAF (felipealexandref)]

it would be nice to have some settings to choose paths (like /data) to give same security level as home. The actual state is too restrictive and limits usability. There are a lot of apps that i can't use snaps just because my files aren't in /home (as i have a small SSD and a big HD).

[Aaron K (akluminus)]

I created an account just to be able to post this. This restriction completely invalidates the ability of some applications to work. I use CloudCompare, and have 2TB of data on another drive that can't be accessed.

You can get around this absurdity by just installing with the --devmode flag.

[Cristiano (cristiano-moraes)]

That is pretty much the reason that I am moving all my apps to Flatpak that deal with this issue way better.

[Hippo Man (hippoman)]

I understand about confinement and how it is an intrinsic part of the `snap` functionality.

This means that there are many commonly used programs which should **never** be converted to `snap`-based architecture, because they are often used in cases where confinement is not appropriate. Unfortunately, a number of such programs have already been converted to `snap`.

For example ... whether the `snap` developers like it or not, there is lots of legacy software such as `vlc` which is currently used by thousands of people around the world to access files outside of the user's HOME directory parition. For example, on my Ubuntu system, I have mounted a separate `/opt` filesystem upon which media and other files reside. I would have to rebuild my system to create a larger `/home` partition and then move those files somewhere under `/home`, simply to get them to be accessible via `vlc`. And a number of scripts and programs would have to be changed to stop referencing these items via `/opt/...` .

The same problem exists for any other `snap`-based program, not just `vlc`. Another example is `chromium`, which is now solely available as a `snap` under the latest versions of Ubuntu. I can no longer use `chromium` to service URL's such as this one: `file:///opt/path/to/something`, given that `/opt` is separately mounted on my system. Again, I would have to restructure my system, simply to get this `snap`-based `chromium` to work like it used to under earlier versions of Ubuntu.

Given that confinement is an intrinsic part of `snap`, this means that only a small, carefully selected set of programs should be forced to be installed as `snap` packages under Ubuntu. General purpose software like browsers, media players, file viewers, etc. should never be forced to be `snap` software ... or for those pieces of software, both `snap` and non-`snap` versions should be offered as standard Ubuntu packages.

Until or unless there is a way for us users to easily enable `snap` software to access whatever filesystems we choose, I am replacing many `snap`-based modules on my system with non-`snap` counterparts.

[Jarno Suni (jarnos)]

Patrick Dinklage, as your employer advises to use /scratch, I suppose your IT administrator could configure the snap apps and mounts so that you could use the local filesystem via a directory under /mnt by applying these instructions: https://askubuntu.com/a/1286929/21005

[Itay Perl (itay-perl)]

Not having /data etc. in the base snap image to mount onto sounds like a poor excuse to me. You could mount a tiny fs on top of the snap image using overlayfs and add the missing directory.

[Sergio Callegari (callegar)]

There should be a way for root to configure the confinement or to make it rely on the usual UGO ownership model. The current setup with hardcoded paths is extremely impractical/limiting in some situations.

[Peter Stalman (sarke)]

I agree. What about just having a `snap` user, and then you can add groups to that user to allow access?

[Zygmunt Krynicki (zyga)]

Hey Itay Perl.

Unfortunately we cannot mount an overlayfs to solve this issue as is is not compatible with apparmor and it would effectively break confinement.

[Chris McDonough (chrism-plope)]

Not that it's worth much, but I will side with the folks who want to be able to configure paths as exceptions to the hardcoded rule of "only allow access to files in /dev, /etc, and /home" either globally or per-snap. I cannot fathom a reason for a central authority to distrust a local administrator to configure exceptions to this rule if they understand the risk.

[Sergio Callegari (callegar)]

flatpak seems to have that nice --filesystem option. Is something like that, including --filesystem=host for when you trust the package, really not possible?

[cha0s (the-real-cha0s)]

I'm throwing in my support for allowing users to run their own systems. I'm almost in disbelief that this issue not only exists, but has been active for 5 years.

I first encountered this using chrome on Linux when trying to download a file. It's not in one of the preordained locations, so it fails. It also fails weirdly and without obvious cause.

It took a long time to figure out that this was even the culprit. This implies that there are many more affected by this who simply will not go through the effort required to discover that this exists, and be left in a state of perpetual discontent.

Having to manually specify "removable media" access? For something like Chrome, vlc, Firefox, Gimp? An intellectually honest assessment of this position shows that it is absurd.

I'm a coder, and I've been running Linux for a long time. I get that a lot of the things I want to do might be seen as awkward edge cases. I'm cool with that. This is not an awkward edge case, though.

This is a bug, not a feature.

P.S. I'm old enough to remember when people kept their private filesystem structure private. You do not need nor have permission to critique my filesystem structure, much less discover it to begin with. You give me an escape hatch, and I don't bother you to update a list of hardcoded paths. It's a win-win.

[rhi (rfc2822)]

Same problem. I regularly use /tmp for downloads and uploads that shouldn't stress the SSD. With Firefox packaged as snap, I can now only download to /home.

[Nathan Hinton (nrhinton)]

Is anyone actually going to fix this? This is a major issue as shown by all of the comments here for many years that has been ignored. I understand that maybe not everyone stores their stuff on external places or in other directories but this should be an option for those of us who do. I have recently started exploring snaps and this is one of the things that I am very dissatisfied about. I know that a lot of Linux systems brag about how they listen to people unlike other people (That is you Microsoft and apple...) but this does not look like listening to what users want and applying it to your system. This is an good tool and could be an amazing tool if some things were done to fix simple things like this problem here.

[Cristiano (cristiano-moraes)]

I don't think they will. Based on the first answers, the problem is at the
core of this system. Fix it means re-write almost everything. At this point
you have only two options:
- Use the classic mode (passing --classic parameter to the Snap) that
remove all restrictions and/or
- Move to Flatpak that does it more properly.
The latter has been my preferential one whenever it is possible.
Unfortunately, not all apps are in both systems.

On Wed, 8 Dec 2021 at 09:06, Nathan Hinton <email address hidden>
wrote:

> Is anyone actually going to fix this? This is a major issue as shown by
> all of the comments here for many years that has been ignored. I
> understand that maybe not everyone stores their stuff on external places
> or in other directories but this should be an option for those of us who
> do. I have recently started exploring snaps and this is one of the
> things that I am very dissatisfied about. I know that a lot of Linux
> systems brag about how they listen to people unlike other people (That
> is you Microsoft and apple...) but this does not look like listening to
> what users want and applying it to your system. This is an good tool and
> could be an amazing tool if some things were done to fix simple things
> like this problem here.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1643706
>
> Title:
> snap apps need to be able to browse outside of user $HOME dir. for
> Desktop installs
>
> Status in snapd package in Ubuntu:
> Fix Released
>
> Bug description:
> Otherwise in many cases the app is semi worthless.
> Ex.
> Install vlc snap, open vlc
> Try to open a file that's not in your home folder, can't do so thru the
> open file browser.
> Same for krita - can only open files in user home or /snap/krita.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.04
> Package: snapd 2.17.1+17.04ubuntu1
> ProcVersionSignature: Ubuntu 4.9.0-1.2-generic 4.9.0-rc5
> Uname: Linux 4.9.0-1-generic x86_64
> ApportVersion: 2.20.3-0ubuntu8
> Architecture: amd64
> CurrentDesktop: Unity
> Date: Mon Nov 21 16:38:19 2016
> InstallationDate: Installed on 2016-11-09 (12 days ago)
> InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Alpha amd64 (20161106)
> SourcePackage: snapd
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706/+subscriptions
>
>

[Martin Sohnius (msohnius)]

This has been going on for at least 6 years now! Even though I am not a Ubuntu man (for historical reasons I am on OpenSuse), it is highly relevant to me, because after the latest OS upgrade, my time-honoured Acrobat Reader 9 (Linux version!) can finally not run any more. So I installed the snap "acrordrdc", which runs a more modern version of the Reader.

But, the restrictions discussed here leave an Acrobat Reader under snapd almost entirely useless: when trying to open a PDF file from inside a browser (e.g. Firefox) or a mail program (e.g. Thunderbird), that application will download the file into the /tmp hierarchy and then call the default application for .pdf with that path as an argument.

Which, of course, won't work if I set my snap-based Reader as the default! And loop-back mounting /tmp somewhere in the home directory does not help either, because the pathname passed on to the Reader will still start with /tmp.

I am now working on a work-around wrapper, but that will be a kludge, not a solution.

The whole issue also raises the silly question: what is so security-sensitive about /tmp?

[Andrew Aitchison (werdnakendal)]

> The whole issue also raises the silly question: what is so security-sensitive about /tmp?

Another, non-privileged, user can write to it, so could leave a trojan (malware) in there ...

Ubuntu has /tmp/user/uid which I assume exists to work around that issue,
but chromium wont let me see /tmp/user/<my uid>/ or file:///tmp/user/<my uid>/

One workaround would be to consistently use a directory you can access through snap, such as /home/USER/tmp, instead of /tmp. (Globally) setting TMP, TEMP, TMPDIR and/or TEMPDIR may help with this ...

https://www.the-art-of-web.com/php/where-is-tmp/ describes some other "solutions" to this problem that have caused problems.

[RichardNeill (ubuntu-richardneill)]

How do you handle this when the user running the snap application is actually a daemon?

I've got a webservice, where one of the tasks is for Apache/PHP to invoke firefox --screenshot.
[This is the only way to get openstreetmap to give you a .png]
It's now impossible, because snap won't let you use your own choice of $HOME.
But Systemd won't let Apache use /home either.

For reference, the code required is:

home=/tmp/my_app_firefox_home #"/tmp" is really inside systemd's private tmp for apache.
mkdir $home
export HOME=$home
timeout 60 xvfb-run -a flock -w 50 $home firefox --screenshot $home/outfile.png $url

Given that every one of the browser-automation tools like phantomjs, casperjs, slimerjs, and wkhtmltopdf is now defunct, how exactly are we supposed to do this task?

This is a simple PHP script; it shouldn't need to create a dedicated user, or do system-level hacks with bind mounts.

[Theo Markettos (caliston)]

I think everything has already been said on this thread so not much to add beyond agreeing with all of it, except to note some of the proposed workarounds aren't feasible politically, even if they are technically:

 * The filesystem layout is decided by your employer / school / etc, and that can't be changed
 * You don't have root on the machine
 * The layout is set because it has to coexist with some other OS (eg Windows)
 * The layout is set because it needs to match some external requirement (eg for documentation purposes, or hardcoded in scripts) and that can't be changed

That multiplies it from a 'make your system ugly to comply' issue into a 'CEO level action' kind of issue, and the latter clearly isn't going to happen.

Ubuntu does not have the power to set the rules in that particular situation, it has to work with the world as it finds it. Basically not every system is like a developer's personal laptop where they have root and can do whatever they like without external constraints.

[private_lock (private-lock)]

What makes this issue so frustrating is that you don't get helpful error messages. So if the snap sandbox denies access, it should at least step to the front and clearly announce, that it did so, instead of secretly failing and letting the application take the blame.

E.g. "Kompare":
$ p=/tmp; touch $p/{1,2}.txt && ls -l $p/{1,2}.txt && kompare $p/{1,2}.txt && rm $p/{1,2}.txt

Results in "The URL file:///tmp/1.txt does not exist in your System!"

YES it does exist - I just wrote the data there myself. It is readable and writeable by my user!

$ p=~/.cache; touch $p/{1,2}.txt && ls -l $p/{1,2}.txt && kompare $p/{1,2}.txt && rm $p/{1,2}.txt

Results in "The diff output cannot be read!"

WTF? I gave you 2 files, why do you complain only about one? Which one?

Where as I can use the file-chooser dialog to open the files one by one - only it cripples the path into something like: /run/user/1000/doc/f036519e/1.txt ... kompare even tries to be nice and remembers this for the next session, when it is guaranteed not to exist anymore.

Furthermore you can only guess by the filename, which folder they are coming from. But when it comes to comparing files, they often start as copies of each other and deviate over time, while the filename explicitly stays - only the crippled folders change ... well, now they change every time in this unhuman hex, that should really not be exposed to my eyes.

Also I better not imagine, what happens, when vlc opens a 10 GB movie - I hope, it doesn't require to duplicate the data on the hard-drive???

Back to our example: while the commandline parameters are given in the terminal, they get an asymmetric error message in the GUI and the terminal keeps perfectly silent. On the other hand, just touching any of the file-open dialogs will spam the terminal in the background with dozens of AccessDenied, even if the final operation succeeds after explicitly choosing the right files.

Up to now, I have no idea, why the .cache behaves differently ... so $HOME is somewhat OK, but don't try anything fishy with hidden folders???

Hidden files are OK though:
$ p=~/Downloads; touch $p/.{1,2}.txt && ls -al $p/.{1,2}.txt && kompare $p/.{1,2}.txt && rm $p/.{1,2}.txt

This tells me, they are equal without the need for a file-chooser. FINALLY!

$ snap version
snap 2.58
snapd 2.58
series 16
ubuntu 22.04
kernel 5.15.0-58-generic

$ snap list kompare
Name Version Revision Tracking Herausgeber Hinweise
kompare 22.08.2 71 latest/stable kde✓ -

[Avio (aviopene)]

6 years and counting. I won't change my FS layout to adapt to snap policies, I want my movies to play from /mnt/nfs, I want chromium to save to /tmp, then I want gimp to re-open the same images without making my home a landfill of temporary files.

And it's not even a deterministic phenomenon! Sometimes vlc manages to open a video outside my home folder! Unbelievable...

[Antti P Miettinen (apm)]

Are the accessible paths still hard coded? Why cannot there be e.g. "snap add-accessible-path" command?

[Andrew Aitchison (werdnakendal)]

Antti> Why cannot there be e.g. "snap add-accessible-path" command?

If I understand correctly, each accessible path must exist as a mount point *inside the snap*,
which means the list must be known at build time.

If run as root, a "snap add-accessible-path" command could rebuild the snap; it may also be possible to make the snap reread the list from a suitable file at run time and reconfigure things. I am not sure that either of these actions would maintain the security of the snap to the satisfaction of the snap team.