@jdstrand @kyrofa @chipaca
snap: flock-chat
Permission denied while trying to attach files from directories like /var, /meta etc.
We are a work chat app and it is a crucial feature to send files in chat from any where in the system where the user has access. It starts working in classic and I also tried to look at some interfaces that can help after connect but non of them seems suitable in this case.
Website: www.flock.com
Twitter: twitter.com/flock
Portals would definitely help here, allowing you to open any file the user can access (without exposing files the user hasn’t explicitly granted access to).
The screenshot looks like a standard GTK file chooser, which is a good sign. On the application side, the main requirements are:
GtkFileChooserNative API.I’m not sure where frameworks like Electron sit with this yet.
There’s still a bit of work to be done on the snapd side, but we’re getting close to a point where people can test this out. It’s probably time to put together some docs for people wanting to test this out.
@jamesh @chipaca
We are using Electron so we don’t have the control to use GtkFileChooserNative API. We are doing a file input and the electron handles it.
Not sure after how much time Electron will implement this and for now its a blocker issue for us to release it to public.
I have also seen other Electron based chat app which are in snap store, all of them use classic confidence. e.g. slack, skype.
Note, while slack and skype do use classic, yes, skype is trying very hard to get to strict mode and there are loads of other electron snaps that aren’t classic.
In terms of whether or not your snap should be granted use of classic, we need to understand why your snap needs it, irrespective of other snaps. It sounds like you are saying that there is a strong expectation that any file the user has access to should be available to the snap. I’m curious how often users actually attach system files as opposed to their own files and if for the time being you couldn’t go the route that the firefox and chromium snaps have gone with plugging ‘home’ and ‘removable-media’ with the understanding that users can simply copy files into somewhere allowed by ‘home’ for those odd times they need a system file. Once the portals work is available to your snap, then this limitation is gone.
Please keep in mind that my question/suggestion above is not a ‘no’ to classic, but instead probing to understand your use case better. Thanks!
We use to provide our app as a web app to our linux users and want to move to a desktop client because of the high demand for it.
We want to make sure we are giving them a better experience then web app so we first rolled it out to internal users and found out that many of them have moved to web again for this particular reason.
Maybe its more common in our company that lots of them need to share files from non-home directories but when a user finds this issue they are willing to go back to web and give us a feedback that if I can do it in web I should be able to do this in a native client, which is blocking us to release our app in this state.
I will love to do it without the use of classic but wants to release it quickly as well because its a business necessity as our competitors like slack are providing this(that is why I mentioned there name) and classic confidence seem to be the quick and simple way around.
We also planned to go with snap only as it provides auto update and is a good platform to distribute our app in various distros. Now this will leave our users to not have that option of getting flock with full access or we need to develop our autoupdate system to provide dmg & rpm as an option to our users like others do as well coz electron don’t provide this for linux (except appImage).
@niemeyer - fyi this thread. Please comment as appropriate.
@evan, @popey and/or @Wimpress - the requirements are understood. Can you perform the other portions of Process for reviewing classic confinement snaps?
I’ve written up some instructions on testing out the portal support as it exists so far:
As I said earlier, I’m not sure how well Electron integrates so far but this should be enough to test.
I have tried this out in my machine with electron-builder but it don’t work. I think the issue is with GtkFileChooserNative not used by electron or electron-builder not providing latest version of GTK. Will test it out by forcing it to build with gtk-3.20. Currently facing issue to build it with electron-builder on 18.04. Will the above work on 16.04?
@jdstrand we’ll go ahead with the the plugs for home and removable-media. For now, could you please add these two to auto-connect.
We are unable to implement portals as of now, as we are completely dependent on Electron and unless Electron moves to using the GTK file chooser, we are stuck with the API they currently seem to be using. Our PMs are hesitant about getting the user to move files to home and then try uploading it again, and the experience is a little broken overall right now, because we don’t get notified when a file is not allowed to be chosen in the file chooser, so we can’t warn the users about moving a file into home and then try re-uploading.
Till portals becomes mainline, and gets integrated into Electron, should we consider classic mode as a stopgap measure?
home already auto-connects so the request would be for only removable-media.
However, you don’t want to specify any interfaces when using classic, so it is either a request for auto-connection or a request for classic. If you consider your snap unusable because a sufficiently large subset of your users expect to a be able to upload from everywhere, then you might consider classic. If you prefer the stronger security stance with strict and some auto-connected interfaces and can wait til Electron supports portals, then you might stick with strict and auto-connecting removable-media.
It isn’t clear from your last response which you prefer at this time. Can you clarify?
Looks like Electron is going to take a while to implement this. We are planning to market this release as soon as possible to existing customers who’ve wanted the Linux app.
We ran some tests and since we are unable to appropriately warn the users about the file selection limitation, it’s causing frustration within the customers’ development teams (when they try to upload logs, etc. outside the home dir).
We wanted to go ahead with classic confinement, it’s going to be of huge help here
@evan, @Wimpress, @popey - the requirements for needing classic are captured. The snap won’t work properly until electron supports portals. Can one of you perform the other portions of this classic request?
The application is uploaded by the upstream developer, appears to be built from upstream source. I’m +1.
Assuming this switches from strict to classic in the store, how will users migrate? As I understand it, they will stop getting updates when it switches to classic. Do we have a ‘fix’ for snaps which migrate confinement?
As I understand it, it is not possible for a snap to transition from strict to classic confinement.
@niemeyer @mvo @zyga-snapd Am I correct?
I think it is possible (at least technically). I’m not sure about the policy surrounding those things.
Granting use of classic to this snap. This is now live.