> 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
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
** Changed in: snapd (Ubuntu)
Assignee: Jamie Strandboge (jdstrand) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
snap apps need to be able to browse outside of
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
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
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
** Information type changed from Public to Public Security
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
snap apps need to be able to browse outside of user $HOME dir. for
Desktop
flatpak seems to have that nice --filesystem option. Is something like
that, including --filesystem=host for when you trust the package, really
not possible?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I agree. What about just having a `snap` user, and then you can add
groups to that user to allow access?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
snap apps need to be able to
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
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
--
You received this
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.
That is pretty much the reason that I am moving all my apps to Flatpak
that deal with this issue way better.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
snap apps need to be able
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.
--
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).
--
You
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
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
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
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
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
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.
--
You received this bug notification because you are a member of Ubuntu
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
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
--
You received this bug notification
@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
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
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
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
For
snap2.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
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. :-(
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
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
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,
> 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
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 <
zygmunt.kryni...@canonical.com> wrote:
> When the feature is available you will be able
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
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!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
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
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
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
>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
There is also this related/identical question on askubuntu:
How to give snaps access to /somedir
https://askubuntu.com/q/1033344/34154
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
Okay, i tried open the file after re-installing vlc via --classic, still
no dice... wth?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
snap apps need to be able to browse outside of
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..
--
You received this bug
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).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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".
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@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
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:
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).
--
You
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
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
@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
/lib is allowed via the AppArmor base abstraction and /dev directory
reads is allowed as a convenience (apparmor and device cgroups mediate
device access).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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..
--
You received this bug notification
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
@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
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?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
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
I cant play videos from my ntfs partition using vlc player. I get "access
denied" error.
Fix this absurd problem please.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
snap apps need
@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
** Changed in: snapd (Ubuntu)
Assignee: (unassigned) => Zygmunt Krynicki (zyga)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
snap apps need to be able to browse outside of user
The new "classic" confinement will fix this.
** Changed in: snapd (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
snap apps need to be
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..
--
You received this bug
It is just as bad (if not worse) in unity8.. but I think a different
bug needs to be filed with other breakage.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
snap apps need to be
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: snapd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643706
Title:
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
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
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...
--
You received this bug notification because you
72 matches
Mail list logo