Open hadess opened 4 years ago
Yes. But is there a request somewhere to have something to manage permissions easily?
I'm honestly not sure. The Flatpak infrastructure is such a maze of separate repositories and associated issue trackers that, for the things I've already found an answer to, it's literally taken me months of off-and-on searching to figure out where they're supposed to be reported... usually finally discovering that they already have been in the process, but using that one keyword I forgot to try searching for.
(eg. "Flatpak would really benefit from being able to grant Discord access to publicly routable IPs only, and granting LAN stuff access to the local subnet and non-routable IPs only" "...oh, it's been reported. It's just waiting on reworking the lower layers so that doesn't require root permissions to enact".)
For all Bugzilla's archaisms, that's one thing Mozilla does get right. You pick a top-level product and they'll search for dupes in all contained components and, once you've reported it, triage it into the right one for you.
There is nothing that is dictated, only something that is proposed and subject to discussion. If there is no proposal, there is nothing to discuss, therefore nothing to do. The thing is to have a proposal created by a small number of people (or interactions between people). When you have it, you offer it to others (GTK and QT devs). If they want to collaborate, they will tell you what is possible, what is not and you adjust your proposal. That's basically what we've done here.
Ahh. So we were talking at cross purposes. Sorry about that.
It's not easy as I thought. If we do this, we must request to grant access to the files and folders that the application wants to access. It would indeed be strange to see a dialog asking for access to neighboring files and folders, especially if it is requested when opening the application. Asking before the "Open" dialog wouldn't be consistent either. So, I leave it as it is.
By "on first use", I meant "The first time you click OK in an Open dialog, a second 'Oh, it'd also like access to adjacent files' dialog follows", not "on first run".
(Sort of like how your web browser will pop up a prompt when the website calls the function to request for geolocation information and you haven't said "Yes, remember that" before.)
Ahh. So we were talking at cross purposes. Sorry about that. Thank you! Maybe I worded it wrong too, because I didn't understand your "on first use" comment.
As for "on first use", I kept the dialogue. You can see this in the latest mockup below (if there is no "read-only" support in the file picker, nothing is displayed; if there is support, something is shown).
To summarize:
*_files
or, ideally, "get filename"+_files
. However, Firefox, for example, translates _files
. So, if specific folders are used, remember that they can be translated.Sorry for forgetting to reply yesterday.
As for "on first use", I kept the dialogue. You can see this in the latest mockup below (if there is no "read-only" support in the file picker, nothing is displayed; if there is support, something is shown).
I'm not sure the "already has been granted at least one time" dialog is worth the added complexity (both to the programmer and to the end user) of displaying an alternative dialog and requiring that the portal host track that detail when you've never said "Always".
It's like drawing the distinction between "cookies never set" and "cookies cleared".
If an app matches a filename (e.g. subtitles), maybe also something to limit access to files that have the matching filename and type/extension?
The problem there is that, for example, as a lazy convenience to pretty up my launcher for emulators which take CD images, I'll often rename the CUE file to a more human-friendly name without going in and editing it so I can rename the BIN file (which is probably named after the disc's volume label or the Sony catalogue number or something else in that vein).
(There may also be "some other tool uses a hash database to identify these things" reason to leave the CUE file's contents unedited.)
or, ideally, "get filename"+_files
Again, I sometimes rename the .html
file without bothering to go in and edit the paths so I can rename the folder.
Given that I'm a programmer and a perfectionist, I imagine this is more common in the general user base than with me.
Kind of reminds me of that "Deleted the _files
folder... where the hell did my HTML file go?" moment when I discovered that, on Windows on NTFS, Firefox was using some kind of feature of NTFS metadata to bind them together as a single deletable unit without being able to alter the "Are you sure you want to delete that?" prompt.
(I leave Firefox on "HTML, Complete" and just delete the _files
folder when all I want is the HTML since it has no "just this time" option for changing the format to save as.)
Limit access to file types/extensions. Access to subfolders is limited to defined file types/extensions.
Is this mandatory or optional? I imagine allowing all would be desirable for something like Visual Studio Code which supports a ton of different file extensions even before you install addons... not to mention trying to guess every random non-standard-but-by-convention extension programmers may use for their custom DSLs.
So: I really think we should keep this very simple. Upon picking a file from the file chooser, a dialog appears saying something like "$APP_NAME wants access to folders and files in this folder. [ Grant Access | Reject Access ]". The main limitation should be something like an app not being able to request full access to $HOME
this way. Otherwise, we keep it simple. Allow the app to access the adjacent files and folders for that session if the user allows it. Any other limitation risks requiring more and more specific solutions for different tasks.
That would certainly be something that could be refined later... though not having some kind of Remember/Always option would still likely prompt me to just go into Flatseal and open up the manifest permissions to avoid the annoying second click on each Ctrl+S of a Firefox Save As for an HTML file, or whatever else.
EDIT: If I didn't know how to do that, I could easily imagine prompt fatigue setting in, where I stop paying attention to which application is requesting the extra permission and just habitually grant it whenever prompted.
@ssokolow:
I'm not sure the "already has been granted at least one time" dialog is worth the added complexity (both to the programmer and to the end user) of displaying an alternative dialog and requiring that the portal host track that detail when you've never said "Always".
It's like drawing the distinction between "cookies never set" and "cookies cleared".
I did this in order for users to know that they have already acted on the dialog and so that there is no confusion with other dialogs requesting access to neighboring files (other applications) because of the same type of user interface (similar appearance). However, this is purely speculative.
Concerning the associations by names, it is also an addition (an improvement for the future for example), but it is only for the applications which act this way. Maybe the web browser example wasn't the best because I didn't know how exactly it worked.
Limit access to file types/extensions.
Access to subfolders is limited to defined file types/extensions.
Is this mandatory or optional? I imagine allowing all would be desirable for something like Visual Studio Code which supports a ton of different file extensions even before you install addons... not to mention trying to guess every random non-standard-but-by-convention extension programmers may use for their custom DSLs.
It is mandatory for better sandboxing. For IDEs, it depends on whether file extensions can be grouped (and identified) as the same type. Maybe something needs to be done here. I also know that GNOME Builder can open directories (the OpenFolder "portal"?), so maybe something can be done on that side (if you also open directories with VS code)?
@BrainBlasted:
So: I really think we should keep this very simple. Upon picking a file from the file chooser, a dialog appears saying something like "$APP_NAME wants access to folders and files in this folder. [ Grant Access | Reject Access ]". The main limitation should be something like an app not being able to request full access to
$HOME
this way. Otherwise, we keep it simple. Allow the app to access the adjacent files and folders for that session if the user allows it. Any other limitation risks requiring more and more specific solutions for different tasks.
My goal is to have stronger sandboxing and let the user know what the app intends to do. If you choose "$APP_NAME wants to access folders and files in this folder. [Grant access | Deny access]", why should I grant access if I don't know what the app intends to do with them?
Except that some of the stuff on Flathub is already "We refuse to compromise on user experience, so we're using filesystem=home
(or even filesystem=host
)".
What you propose would push people with that mindset to decide that granting filesystem=home
or filesystem=host
is the better choice for want of an "Allow granting *
adjacent to whatever $HOME/narrower/scope/...
the user pics with their file chooser".
(Remember that, for a lot of people, Flatpak isn't about security first, but about ensuring access to newer packages than their distro offers in the repos... and I saw dispute in the tracker for the Discord Flathub package over whether it should be about security, with people basically saying "You don't want to give people filesystem=home
for their file-uploading pending Electron gaining GtkFileChooserNative? I'll be setting an override for that but, if I didn't know how, I'd be dismissing Flathub as not fit for purpose.")
Here's a list of just the things I have installed where my overrides contain !home
or !host
plus some narrower manifest grants:
Granted, the Arduino IDE, LibreSprite, Pixelorama, Sweet Home 3D, Blender, Bustle, appstream-glib, Godot, Handbrake, Inkscape, OpenTTD, and PPSSPP don't delegate to QFileDialog or GtkFileChooserNative or offer their own portal support upstream, but that still leaves Calibre, DOSBox-X, Ungoogled Chromium, AntimicroX, LMMS, FocusWriter, KCachegrind, and Krita.
Arduino IDE, Bustle, Handbrake, and Inkscape appear to use GtkFileChooser, appstream-glib is a CLI tool, Sweet Home 3D uses Swing's Windows 9x knock-off file chooser, Blender, Godot, LibreSprite, and OpenTTD build their own file choosers, Pixelorama is Godot-based, and I'm not sure why PPSSPP needed relaxed filesystem permissions.
(That said, anything GTK-based that doesn't pick up the portal file chooser might be intentionally opting out. For example, Handbrake presents a file picker so you can choose a device or ISO but also puts you in a "needs adjacent files" situation if you want to convert a folder of pre-ripped VOB files as is produced by something like dvdbackup
.)
Calibre, AntimicroX, LMMS, FocusWriter, KCachegrind, and Krita are Qt-based. DOSBox-X and Ungoogled Chromium delegate to something portal capable, though the former is SDL-based and the latter uses its own toolkit.
@ssokolow: Is your last comment for me? If so, could you explain more simply what you mean (what are the issues)?
It's a reply to this:
It is mandatory for better sandboxing. For IDEs, it depends on whether file extensions can be grouped (and identified) as the same type. Maybe something needs to be done here. I also know that GNOME Builder can open directories (the OpenFolder "portal"?), so maybe something can be done on that side (if you also open directories with VS code)?
Basically, I'm saying that, if you don't allow *
as a valid filter for what adjacent files to be granted, you're likely to run into various maintainers just sticking with filesystem=host
or filesystem=home
and bypassing the portal entirely in order to ensure that their standards for end-user experience are met.
It's that whole "If you push too hard, you'll get nothing" dilemma paired with Flathub's emphasis on presenting applications in their upstream forms and maintainers' general unwillingness to effectively maintain a following fork.
@BrainBlasted:
"$APP_NAME wants access to folders and files in this folder. [ Grant Access | Reject Access ]".
Here is another phrasings:
If you want to additionally suggest the user to get information, the simplest would be something like (directly displayed or hidden behind a button):
@ssokolow:
OK. It's no problem to add an "All Files" option. With this, we are then in a "best effort" situation.
However, if the apps don't use a native file picker, neither solution will work (both solutions are after selecting a file to open in a native file picker), unless we don't ask for it (like setting filesystem=host
or filesystem=home
), or ask before applications open a file (i.e. when the application is launched from its icon or from a file opened from a file manager - maybe that's what you meant with "on first use"?). Or did I miss something?
See website.web for information on how $APP_NAME works.
This could easily get long and complex if website.web is something like http://longprojectname.github.io/en/1.2.3r4/manual/part5/chapter6.html
(or, more likely, something like https://github.com/joncampbell123/dosbox-x/blob/master/INSTALL.md)
Perhaps a simple, fixed size "more info" link that can be right-clicked to Copy URL if you don't want to open it in the default browser?
OK. It's no problem to add an "All Files" option. With this, we are then in a "best effort" situation.
Flatpak is fundamentally a best-effort solution exploring how far "best effort" can feasibly go. Otherwise, you'd be implementing a capability-based system like WASI.
There's also plenty of precedent for this "allow the maintainers to exercise discretion, then encourage them to be reasonable" approach. That's what filesystem=host
fundamentally is.
(Though having a blacklist of particularly sensitive things in $HOME
that need to be explicitly un-blacklisted in the manifest if your app is something like a a graphical SSH configurator would also be in line with how filesystem=host
behaves.)
A big part of the solution you want is going to be patching flathub/linux-store-frontend to display addons.mozilla.org-style permissions information as part of putting ambient pressure on maintainers who grant permissions too freely, and patching GNOME Software and KDE Discover to display permissions information in a form comparable to the flatpak CLI.
(Last I checked, GNOME Software just had a "Sandboxed" badge even when using filesystem=host
, prompting some famous FUD, and KDE Discover just treated APT/RPM/etc. and Flatpak the same, visually.)
However, if the apps don't use a native file picker, neither solution will work (both solutions are after selecting a file to open in a native file picker), unless we don't ask for it (like setting filesystem=host or filesystem=home), or ask before applications open a file (i.e. when the application is launched from its icon or from a file opened from a file manager - maybe that's what you meant with "on first use"?). Or did I miss something?
I was listing them all, then separating the ones that are and aren't relevant. There are effectively four categories:
filesystem=host
or filesystem=home
anyway for lack of the permissioning they need (in scope)As three examples of stuff among that list of things I personally have installed which are in-scope:
Arduino IDE is an example of something that uses GtkFileChooser or otherwise opts out of the portal but, with this feature, should be capable of being packaged with a trivial patch and an appropriate manifest. (Like something like Visual Studio Code, it needs access to a "project folder" for the file you open.)
Calibre appears to use the portal (Setting QFileDialog::DontUseNativeDialog
opts out of the KDE file dialogs by definition, so the Flathub maintainers would have to provide a Flatpak-specific patch to opt out of it), but it imports HTML with associated subresources so it uses filesystem=host
.
Cachegrind dumps don't embed all the source they reference, so KCachegrind uses filesystem=host
despite using the KDE file dialogs.
Totally agree for the More Info link.
Regarding my design, the dialog remains the same. The idea is to have file types/extensions, and recommend developers/maintainers to define extensions before using an "all files" option.
(´All files’ is shown in the dialog)
@BrainBlasted:
"in order to work properly" might not be appropriate if the application can work without having access to neighboring files and/or folders. Maybe something like "$APP_NAME may want to access neighboring files and folders to work. This access allows to take advantage of all its features.", and a message to let the user know if the app can work without them (e.g. "This app may work without them"). The goal is to make it clear that granting them access makes sense.
@ssokolow:
Now, in GNOME Software:
For IDEs:
So for IDEs, do you have any cases where neighboring files/folders would be really useful?
@BrainBlasted:
The limitation to specific file types/extensions was there in case you open a file in "parent" folders (home, documents, photos, images, videos) so the app can only read a limited set of files, especially if there are other file formats in those folders that the application is not supposed to open (this will especially be the case for the Documents folder). Note that this is something that can be done (if desired) without having a UI.
Now, in GNOME Software:
Good to see they've fixed that. (And I say that with the utmost sincerity. It's worse than useless to say something is "sandboxed" without elaborating.)
So for IDEs, do you have any cases where neighboring files/folders would be really useful?
There are various project tools where they expect you to pick the project file using a file picker... either because it has no standardized filename or to avoid breaking legacy support for "multiple projects intermingled in the same folder".
The Arduino IDE is an example of this that I actually have installed. You pick the .ino
file with the file picker, which is a C++ source file with a non-standard extension, and the Build and Upload buttons just assume that, when they launch GCC, it'll have access to what's being referenced by any #include "local_file.whatever"
lines you use in your source.
There are also situations such as various Vim configurations where you pick a file, but then you type something like :make
or !<command name>
and it just runs a vimrc
-defined or user-specified command in the working directory of the file you picked, without any form of "project file" as the editor understands it.
(Hell, it's a common approach for me to launch gvim
from the command-line or by double-clicking a file and then use Vim's internal Tab-completion, file-finder plugins, or "open selected path" to open additional files in the same project as needed.)
Also, while it's not an IDE, see my previous comment about Handbrake, where the "Open Source" file-chooser dialog is used for both single-file stuff, like ISOs and device nodes and multi-file things, like folders full of VOB+BUP+IFO files dumped using tools like dvdbackup.
I added "All Files" now (but I need to tweak some things before posting).
And as I said in a previous comment, the recommendation for developers and maintainers would be to specify all known extensions and use "All Files" as a last resort.
For convenience, I also added the ability to have custom categories to group multiple extensions that don't go together due to different MIME types (it's only to fit the UI I designed).
And as I said in a previous comment, the recommendation for developers and maintainers would be to specify all known extensions and use "All Files" as a last resort.
Of course. "All Files" would be to this portal as filesystem=host
is to manifest permissions.
For convenience, I also added the ability to have custom categories to group multiple extensions that don't go together due to different MIME types (it's only to fit the UI I designed).
I'll have to wait and see an example to weigh in on that. It could be good or bad depending on how it's designed.
For custom categories, I thought of doing the same as for "Unknown Files": orange and invite to click the info button, as well as having a message telling the user that the category name is custom and the list of extensions in the info dialog.
However, this might require a helper tool to check if extensions have a category (like image, video, audio). For example, I just saw that comic archive extensions are categorized as "Other Files" with type "Comic Book Archive" (I'm referring to file associations in GNOME settings). The dev/maintainer checks with the tool if these files have a category (in the tool: enter the extension, and the tool displays it with its category/file type; the dev/maintainer can then use the category /type to show all file extensions belonging to it), and then can decide to put them in a Comics category instead of putting them in an "Other Files" category. Unfortunately, as usual, my knowledge is limited, so I hope you see the thing...
Well, I thought about it, and now here is what I think:
@BrainBlasted's design
My design
Note
For custom categories, I thought of doing the same as for "Unknown Files": orange and invite to click the info button, as well as having a message telling the user that the category name is custom and the list of extensions in the info dialog.
My main concern there is that, if this is a security tool:
How do you prevent a malicious app from assigning some sensitive but obscure extension to an innocuous-sounding category, so the user grants permission more readily? (And, if you have guardrails, why not just put that effort into improving the mimetype database that provides the predefined categories?)
Weren't you concerned about the height of the dialog? How do you prevent it from becoming too tall? ...especially when a scrollable list in this era of overlay scrolling could hide stuff below the fold?
However, this might require a helper tool to check if extensions have a category (like image, video, audio). For example, I just saw that comic archive extensions are categorized as "Other Files" with type "Comic Book Archive" (I'm referring to file associations in GNOME settings). The dev/maintainer checks with the tool if these files have a category (in the tool: enter the extension, and the tool displays it with its category/file type; the dev/maintainer can then use the category /type to show all file extensions belonging to it), and then can decide to put them in a Comics category instead of putting them in an "Other Files" category. Unfortunately, as usual, my knowledge is limited, so I hope you see the thing...
I think it'd be better to put the effort into improving the shared metadata so everyone can benefit.
I really think it's necessary to have wording to let the user know that the application wants to access the files and/or folders for a reason. For example, "$APP_NAME wants to access nearby files and folders, enabling additional features".
But is that actually gaining you anything or just making you feel better?
I'm reminded of George Carlin's "people add extra words when they want to make things sound more important than they really are." routine where he contrasts "boarding" vs. "boarding process" and "shower activity" vs. "showers"
It seems intuitively obvious that it would enable extra features. Otherwise, why would the application want it? ...and if the "feature" is "stealing your banking information", an extra label like that will just make the request seem more legitimate.
Encourage the user to click only the information button (which shows extensions and subtype when there is no extension) for "Other Files" (old name: "Unknown Files").
Encourage them more, maybe, but those categories can be important to look into regardless.
Some audio or video files are as safe as is possible when parsing untrusted data, while others were made into attack vectors via their container format's "URL where you can get a key for the DRM" metadata. (WMA/WMV/ASF come to mind.)
Some documents are plaintext, while others could contain macro viruses.
etc. etc. etc.
Need a database of file types and extensions. It allows developers/maintainers to simply define extensions in the manifest. Either allow custom categories (if custom, encourage the user to click the info button) or encourage developers/maintainers to improve the database (category approval, "peer review").
My advice is to build on the existing XDG mimetype database that powers file associations via the MimeType=image/x-xpixmap;image/x-xbitmap;image/x-tga;image/x-portable-pixmap;image/x-portable-graymap;image/x-portable-bitmap;image/x-portable-anymap;image/vnd.microsoft.icon;image/tiff;image/svg+xml;image/png;image/jpeg;image/gif;image/bmp;application/x-navi-animation;
key in .desktop
files by letting the system maintain a central mapping from mimetypes to extensions and/or file headers.
(That'll also make it easier for upstream maintainers to keep .desktop
files and manifest permissions synchronized.)
As the Shared MIME-info Database spec details, relying on the system mimetype database will allow you to resolve a mimetype name to:
*.foo
globs (how they're actually mapped to extensions, which isn't limited to extensions in cases like extensionless ChangeLog
or LICENSE
/COPYING
files)magic
entries, with optional priority
attribute, which define how to identify files based on their headers (This is how things like Nautilus are able to present those "This has a .foo
extension but is actually a Bar-format file. Please right-click and manually choose an application from the "Open With" submenu." dialogs.)magic
to allow distinguishing between different XML-based formats.Here's the example definition from that spec:
<?xml version="1.0"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
<mime-type type="text/x-diff">
<comment>Differences between files</comment>
<comment xml:lang="af">verskille tussen lêers</comment>
...
<magic priority="50">
<match type="string" offset="0" value="diff\t"/>
<match type="string" offset="0" value="***\t"/>
<match type="string" offset="0" value="Common subdirectories: "/>
</magic>
<glob pattern="*.diff"/>
<glob pattern="*.patch"/>
</mime-type>
</mime-info>
The database is not really a security tool. This is to encourage users to inform themseves in case an extension is not known (and that's why I didn't mention the orange color anymore in my last comment).
The support tool is just letting a maintainer/dev check if an extension is known. Because the best is indeed to add extensions to a database (the shared database), they need to know about it. This support tool can be an app or web-based.
It seems intuitively obvious that it would enable extra features. Otherwise, why would the application want it? ...
Sorry, but you can't assume what you think is what everyone else would think. However, if there is an info or "?" button, there will clearly be less need for "additional/extra features" in the wording. With or without the words "additional/extra features", both can potentially encourage the user to click the info or "?" button (if there is one).
and if the "feature" is "stealing your banking information", an extra label like that will just make the request seem more legitimate.
So never use an app:
Even if you don't have those extra words, what will make you not allow access, and especially if you think it's obvious that requesting access to neighboring files allows extra features?
My plan is as follows for now:
Sorry, but you can't assume what you think is what everyone else would think.
I don't disagree with that. However, I think your chosen phrasing is not functionally different from "This program wants these extra permissions so it can use them."
...and the answer is "Oh, thank goodness. I was worried it wanted them because the maintainers just liked requesting more permissions than they were going to use".
...plus, with your phrasing, if they refuse it, the program might crash or display an "ERROR: Couldn't open file. Exiting." dialog... and then you've misled the users.
It feels like performative security without any justification that it has any benefit other than playing into your perception of what's necessary to make people safer and, from my own anecdotal experience, it won't.
I've worked with technically skilled users, with my mother's artist friends, who are now in their 70s or 80s, and various people in between and my experience is that people react in one of three ways:
They find the fact that they're being prompted inherently unnerving because they're not trained in the minutae of this sort of thing and they know it, so they either call someone they trust to make the decision or they just guess. "This will enable extra features" doesn't help there, because they don't know what those extra features are while being prompted and may make it worse because, if they guess "no", and the program refuses to run, it will make them feel less confident in their ability to use the program at all.
They feel confident in their ability to use it, but don't have time to deal with this mess and just allow things.
They are security conscious and will research why the permissions are necessary before granting them.
None of these three cases are helped by a blanket message tying the prompt to "additional/extra" features which may turn out to not be "additional/extra" after all.
(Especially in a case where it's being specified by the manifest on an unmodified build of the upstream source which is likely to either present mysterious failures when the subtitles refuse to display ("I see the file right there!" after forgetting they refused the permissions) or present a cryptic error when you invoke the hitherto under-tested "Managed to open the .project
/.cue
/etc. but the OS returned failure when trying to open the files it references" case.)
EDIT: Forgot to reply to this:
The database is not really a security tool.
I'd say it's still a better to query the shared mime database rather than giving the application full control.
...and if it's really in that vulnerable a state, you probably need to harden it anyway to prevent one Flatpak application from manipulating the behaviour of other applications outside the sandbox by contaminating the mimetype data through means intended to allow them to declare their file type associations.
"additional features" has nothing to do with security... It was only to vaguely give a reason for this request. Don't forget that there is also "More info"... The only security concerns the sandboxing of neighboring files and/or folders (which is not presented to users in any form). Remember that this is only a proposal, not the ideal. I had first suggested "work properly" which was even more inadequate. But, we can do without it with the info/"?" button or the "More Info" label.
...plus, with your phrasing, if they refuse it, the program might crash or display an "ERROR: Couldn't open file. Exiting." dialog... and then you've misled the users.
If an application crashes because it cannot access adjacent files/folders, there are two options for the dev/maintainer:
Example (from another design; the phrasing is another thing):
I'd say it's still a better to query the shared mime database rather than giving the application full control.
...and if it's really in that vulnerable a state, you probably need to harden it anyway to prevent one Flatpak application from manipulating the behaviour of other applications outside the sandbox by contaminating the mimetype data through means intended to allow them to declare their file type associations.
The database is queried. The only thing declared in the manifest are the extensions, unless the portal (with the database) can guess what the app wants to open... As for the "custom category" it was to specify the category in the manifest with the relevant extensions in case it is known that the database cannot recognize them or if they are not classified (and this is only informative). There is no access to the database. Declaring which extensions the app wants to open is just telling to flatpak what to sandbox.
Based on what has been said (mostly by you @ssokolow), I think the following (having the GNOME desktop and @BrainBlasted's simple solution in mind):
So what to do? Here are some thoughts:
and applications based on a library (for example, a music player).
They don't use adjacent files/folders...
Having a required/optional distinction which behaves similarly to how Firefox extensions do, where they're declared in the manifest but some are like the existing filesystem
permissions while others are in a "May prompt for..." section would resolve a lot of potential issues as far as user experience goes.
It'd also provide a natural place (flatpak override
or Flatseal) for users to customize the required ones. For example, if you have a tool which operates on BIN/CUE pairs and then find yourself manipulating a lot of DOSBox-based GOG.com games where they rename the .bin
files to .gog
files for some reason.
Having a required/optional distinction which behaves similarly to how Firefox extensions do, where they're declared in the manifest but some are like the existing
filesystem
permissions while others are in a "May prompt for..." section would resolve a lot of potential issues as far as user experience goes.
I don't understand... Do you mean not asking for some files but asking for others, or asking by file type/extension?
A reason is always given in the dialogues. For example, if an application wants to take screenshots, this reason is indicated in the title and in the text of the dialog box. However, in this case, we have a specific reason that concerns only one feature. This is not the case with adjacent files/folders. By itself, we're not asking about a specific feature of an app: we're asking about file/folder access. However, access to neighboring files/folders is not an app feature: it is a feature that allows access to other features in an app (unless that app needs it to work properly , such as project file-based applications). An example of enabling a feature of an app is the ability to browse files with an image viewer. It is therefore difficult to know exactly what to do.
This makes perfect sense.
In GNOME design, at least for now, we only have two response options: Deny and Allow. The design with three options breaks this design. Also, I don't know if we can have additional messages or an info button (I don't think so).
This is problematic. A "remember my chioce" is pretty much a must here. I don't think the protocol discussed here should be lacking only due to one DE's missing feature. For one type of application, I want to check that "remember this choice" checkbox. For others I wouldn't.
The protocol should not make it difficult for implementations to potentially have a one-shot / forever toggle (though it's fine for it to be optional on GUI implementation side).
I don't understand... Do you mean not asking for some files but asking for others, or asking by file type/extension?
I mean being able to specify something akin to --filesystem
in the manifest, but with something along these lines:
--requires-adjacent-files=<pattern>
will display an install-time permission prompt and then assume "Always allow" without displaying a prompt dialog. (For things like a disk image editor/browser/extractor which supports BIN/CUE or BIN/TOC pairs.)--prompted-adjacent-files=<pattern>
will display an install time "May prompt for permission to ..." section in the permissions prompt and then automatically display such a prompt when using the file chooser portal, to retrofit support onto applications that don't interact with the portal APIs directly..cue
file and then only prompt for the extensions actually referenced by it.)This is problematic. A "remember my chioce" is pretty much a must here. I don't think the protocol discussed here should be lacking only due to one DE's missing feature. For one type of application, I want to check that "remember this choice" checkbox. For others I wouldn't.
The protocol should not make it difficult for implementations to potentially have a one-shot / forever toggle (though it's fine for it to be optional on GUI implementation side).
Be reassured, I never suggested that this should block the protocol (and I think for people who want to, there should be Deny/This Time/Always options in GNOME).
So opting for differentiation, depending on whether the application absolutely needs adjacent files/folders or not (as demonstrated by @ssokolow).
- To be consistent with how the file chooser portal works, applications which don't declare anything in the manifest may still directly invoke the prompt via D-Bus to support conditionally prompting for elevated permissions. (eg. So they can open a
.cue
file and then only prompt for the extensions actually referenced by it.)
Could you give an example?
I thought I did with the (eg. ...)
that you quoted. Could you elaborate on what kind of example you're looking for?
How it works "visually" (the app do this, then do this, the prompt appear at this time)
It would look identical to the --prompted-adjacent-files=<pattern>
case (Click OK in the file chooser and the neighbouring files dialog pops up), except that it would only happen some of the time because, instead of the manifest indicating that it should happen whenever the file chooser is invoked, the application is reading the file from the file chooser and then manually issuing D-Bus requests for the neighbouring files dialog as needed.
Ok thank you. Sounds more or less like what I originally wanted. However, again, the dialog should make sense to the user...
@xhorak:
Neighboring files/folders is about opening files, not writing them: only files or folders that will be opened with the adjacent files/folders feature will be writable.
Adjacent files/folders to write were not discussed. Maybe this is something to be discussed in a new issue or it will delay the coming of the feature discussed here.
@hadess, @BrainBlasted: What do you think?
I just assumed it would be supported since:
This was something that got overlooked in the process... However, this issue was mostly about opening files, not writing them.
This may work if you open a project file (or folder) first. However, we mostly talked about accessing adjacent files or folders, which assumes they already exist. And by access, we've always meant to open (and indirectly write to files that can be opened). Now it's up to @hadess and @BrainBlasted (who wants to work on it) to clarify on those cases.
Saving a web page and its resources is a different case because you are not opening a file first.
Ahh. I imagine we'll probably see things like Firefox, various IDEs, etc. continuing to use filesystem=host
or filesystem=home
then.
I know that it makes it practically useless for me since most of the things that only need to read stuff still don't use portals (GtkFileChooser
, DOSBox's imgmount
command, etc.) while the things that would benefit from a security boost most (browsers, code editors, an SQLite database editor GUI, etc.) need to create adjacent files.
(And the ones that could benefit from it are already easy for me to Flatseal into a "read-only access to just my media folder or whatever, no network access" configuration that will gain little, security-wise, from an adjacent files portal.)
I assume that with neighbor files/folders, access will be given to the folder where they are located, so write access will also be granted to it. There are only two issues: (1) (for me) the sandbox mechanism is supposed to be triggered by "opening" a file, which rules out the "saving a web page" case, and (2 ) the wording that asks "to access neighboring files/folders", a wording that, to me, does not imply that new files can be created.
If we forget the "save webpage" type case, I guess new files and folders could be created using "adjacent files/folders". However, it will be an inappropriate use of this feature if the wording is not adjusted. So if (1) is correct and (2) is adjusted, it might work. But only flatpak developers can confirm it or not.
For filesystem=host
and filesystem=home
there is still my proposal with extensions to have some form of sandboxing if desired.
That's the only thing I can say on the subject.
(1) (for me) the sandbox mechanism is supposed to be triggered by "opening" a file
I thought it was supposed to be triggered by picking something via org.freedesktop.portal.FileChooser
, which has both OpenFile
and SaveFile
methods... the latter of which, things like Firefox's Ctrl+S delegate to.
I really don't know how it works (I'm still not a developer).
The only thing I can say is that it won't be relevant to ask users if they agree to grant "access to neighboring files" when saving a file.
by picking something
Just to be sure (for my understanding), you mean "when a folder is selected"?
Just to be sure (for my understanding), you mean "when a folder is selected"?
No. SaveFile
requests a file picker so the user can set the output filename. There's a separate method named SaveFiles
for generating a directory picker with the intent to save files and letting the application append filenames the user can't edit.
org.freedesktop.portal.FileChooser
has three methods:
OpenFile
will display a file chooser which requires you to pick a pre-existing file and has boolean multiple
and directory
options to control whether you're allowed to select multiple files and whether to display a directory picker instead, respectively. It corresponds to GtkFileChooserNative
with Gtk.FileChooserAction.OPEN
or Gtk.FileChooserAction.SELECT_FOLDER
.SaveFile
will display a file chooser which lets you select a parent directory and either type a filename or select a file to overwrite. It corresponds to GtkFileChooserNative
with Gtk.FileChooserAction.SAVE
.SaveFiles
will display a folder chooser which lets you select an existing directory or create a new one. It corresponds to GtkFileChooserNative
with Gtk.FileChooserAction.CREATE_FOLDER
....but, that distinction aside, yes. I was imagining the dialog would appear when the user clicks OK in the open/save dialog.
The only thing I can say is that it won't be relevant to ask users if they agree to grant "access to neighboring files" when saving a file.
So we adjust the phrasing. Letting a quirk of the phrasing restrict a fundamental concept that the code you're wrapping expects to hold true is a sure-fire way to make what you've implemented irrelevant.
We're missing a UI that would make it possible to opening a file, eg. a project file, and also give access to the rest of the files in that same directory. This is useful for:
UI-wise we could have:
New use cases, UI ideas, or prior art? Please list them below.