File Set Request (Files With Links to Other Files In the Same Directory)

[Mikenux]

Canceled

[Mikenux]

The proposal has been updated:

• Small wording changes.
• Mention of checks only once.
• When the value of check (4) is "all", the value of check (1) is any.
• Added removal of access to requested files when the app is no longer running.

The changes can be known using the “edited” button.

[Mikenux]

Update 2:

• Clarification.
• Added "A Simpler Portal" (do not implement the "confirm" access permission).

[Mikenux]

Update 3:

• Major update! Please read again.

[Mikenux]

Update 4:

• New section: Fileset Request.
• New check (3a) in Functioning section.
• New section: Open Fileset Method.
• New section: Delay Before Responding.
• New section: Portal User Interface With Portal Code.
• New section: Waiting Window.
• New section: Recommendations for App Developers.
• Two new Questions.

[Mikenux]

Update 5:

• New section: Files Added After Fileset Request.
• Waiting Window section: Clarifications and one option added.
• Questions: Added a question regarding a second option for the waiting window.

[Mikenux]

Update 6:

• The proposal can optionally be opened for a file set where the files are located in different locations.
• Opening file sets where some files have not been accessed before is allowed. Blocking this did not make sense because a file set where the files are all in the same location is usually portable and therefore editable on different computers.
• Clarification.

These changes (made the same day as this comment) can be viewed using the "edited" button.

[adrianinsaval]

I'm not familiar with the process for proposals here, is this something that is being worked on? What needs to happen so it gets worked on?

Beyond that I have some questions, I'm from the perspective of a freecad user/dev trying to understand if links can eventually work with the desktop portal. Currently our flatpak app just has host permissions to wrokaround this.

An app can only make one request for a set of files after the user opens a file via the file chooser, file manager, or drag and drop. Once a request has been processed, whether it has failed, been denied, or access has been granted, any further requests from the app will be automatically denied until the user opens another file via the file chooser, file manager or drag and drop.

what if a linked file also links to other files? This is common in freecad projects. The app would need to read the linked file before knowing it links to other files so it will need to make more than one request to get all the linked files it needs, I don't think secondary requests should be automatically refused, in any case the user could be prompted (and given the option to accept all requests)

(2) The app requests a set of files within a defined time limit (to be defined) which starts when the file selected by the user has been returned to the app. Values: "no", "yes".

If a time limit will be imposed I hope it's a relatively long one or that there is still the possibility of requesting access with a prompt for the user if the time has passed. CAD files can get pretty big and therefore slow to open in big projects, although I'm not sure if links are read and requested early. Considering the case of linked files linking others I mentioned before I think the timer should be reset after the first level of linked files is accessed.

Would this also allow access to files in sub-directories in the same location? This is also common in FreeCAD projects and if I'm being honest any arbitrary relative path from the file is a common thing, can we think about allowing arbitrary relative paths? We can think about prompting the user whenever the app request files in a different directory.

This could be cumbersome for the user:

To ask it to examine the files requested for each file it opens, especially if they has many files with links to other files.
To spot if there is anything suspicious in the case of files requiring the opening of a large number of files.

we could be smart about this, an app requesting a bunch of files of the same extension as the opened file is not so suspicious, the files could be grouped by extensions and the interface could have more highlight to specially suspicious requests like scripts, dot files and directories or anything deemed sensitive

[Mikenux]

Thanks for you interest!

is this something that is being worked on? What needs to happen so it gets worked on?

Unfortunately, I'm not a developer and I don't know if anyone is working on it, or what needs to happen for this.

what if a linked file also links to other files?

The point is that the delay should not be too long, so that the user knows that this is a file to open other files. This meaning is difficult to convey if it is too long or if the user has no indication. This is done to not give users the impression that there is a problem (since with the portal we go from not asking when opening the "project" file to asking when opening it).

Perhaps, given in the proposal that the portal only waits if the file is a "project" file, we can simply display a modal window indicating that the app is processing the file before displaying the requested files. And so on for the following files. Note this does not remove the idea of the delay. What do you think of this idea?

(and given the option to accept all requests)

I'm not in favor of having the option to accept all requests, as that may defeat the protective purpose of the portal (i.e. asking when there might be something suspicious ). Are there so many requests to be made? Do all requests have to be made one after the other? Given the idea in my answer above, maybe I can add a method to make the app perform a request for a given file; for example, the app performs the request when the user clicks on the "project" file.

CAD files can get pretty big and therefore slow to open in big projects, although I'm not sure if links are read and requested early.

Ideally, a request should request all files as quickly as possible. This might require changes to the code that parses a file. The developer who wants to develop this proposal should take into account developers who do not want to make big changes to their apps, more so for cross-platform apps. The time limit to define in the proposal depends on it.

Would this also allow access to files in sub-directories in the same location?

Yes.

We can think about prompting the user whenever the app request files in a different directory.

If this directory is in the same location as the "project" file, no problem. If it's one or more directories from different locations than the "project" file (like a video project), no.

we could be smart about this, an app requesting a bunch of files of the same extension as the opened file is not so suspicious, the files could be grouped by extensions and the interface could have more highlight to specially suspicious requests like scripts, dot files and directories or anything deemed sensitive

Other files may be sensitive to a user because we don't know how they organizes their files. For your suggestion of simplification, why not, perhaps we could simplify after a given number of files requested.

[Mikenux]

Regarding dot files, is there a valid reason for an app to request them when requesting non-dot files at the same time?

[ptomato]

Regarding dot files, is there a valid reason for an app to request them when requesting non-dot files at the same time?

Yes. An Inform XYZ.materials folder may have a .gitignore file inside it, which is autogenerated by the Inform compiler.

[Mikenux]

@ptomato: Did you mention Inform to tell me that there is the case of development, or because Inform is concerned by this proposal? (just to be sure)

[ptomato]

Yes, I'm following this proposal because I'm assuming it's what I'd need in order to allow Inform to access the sibling .materials folder.

[Mikenux]

So Inform isn't a case of naming matching (#1290) then?

[ptomato]

Possibly? I'm just generally trying to follow along anywhere that might be relevant.

[Mikenux]

Ok

[ondrejkolin]

Thanks @Mikenux for putting this together.

Just a small hint:

The required files doesn't have to necessarily neighboring to the file, they can come from a different path. Usecase app.freelens.Freelens on flathub needs access to the .kube/config file, which can include (link) certificates / keys from the FS.

Example:

• name: minikube
  user:
  client-certificate: /home/okolin/.minikube/profiles/minikube/client.crt
  client-key: /home/okolin/.minikube/profiles/minikube/client.key

[ptomato]

That case seems different though, doesn't it? You can grant access to ~/.kube/ and ~/.minikube. Or are there other things in those paths not meant to be shared

[Mikenux]

@ondrejkolin: The request of files from different paths is considered. See the note on the first line of the proposal.

In my opinion, I don't think it's reasonable to allow the request for files in config folders, especially since these are not visible to the user by default. Only dot files and dot folders located in user-visible folders are allowed.

Also, you are talking about acquiring certificates. If the certificate files are standard (or well known), this should be part of a credential portal (there is a discussion about it: #989). However, logically, I would say that we should know which app the credentials belong to, especially when requested from another app. To be discussed.

[Mikenux]

Note that there is also #1290, since the files you mentioned have the same name with different extensions, and if the app opens the first file with the file chooser. However, if a database is used, the addition of the case is subject to evaluation.

[ondrejkolin]

That case seems different though, doesn't it? You can grant access to ~/.kube/ and ~/.minikube. Or are there other things in those paths not meant to be shared - granural control could be important here.

Yeah, that's what I did. In those folders could be actually also private keys to your clusters which you don't want to share.

@Mikenux you are right, although these certificates are not system-wide, they are only used by the binaries, that talk to the cluster API server.

They will "always" belong to non-flatpak apps. Either minikube or others can't be expected to run in flatpak or being controlled by flatpak.

Even I understand the concern system-wide access to files to be problematic, it could be either another permission, or the user should be able to review this. We can't really expect here, that because of flatpak, projects will do the right thing and use correct folders.

Flathub can do the reviews if apps ask for this potentially dangerous permission.

Thank you guys for working on this. I think this one is a big one and 3rd party developers mention it everytime I talk about flatpak with them (they don't really understand why it's such a problem where other® similar container solution doesn't care about it at all!

[Mikenux]

I don't know how people talk about this proposal, but don’t forget that a request can only be made after opening a file via the file chooser or via a file that the app already has access to. In addition, the opening of this file will be indicated in the user interface, while reflecting that the list of requested files follows the opening of a file that contains links to these files. This is not a proposal to request a file at any time.

Note that if an app has the ability to acquire arbitrary permissions, especially file permissions, the permission request here might not be presented to the user.

[ondrejkolin]

But what if the app can't know what it will ask for before it opens the "main" file which contains the references. My idea was: 0. Use filepicker to open the "project file" in case of projects and retrieve a "token" 1. App Parses the file and uses the token to make an async request through the portal for extra files 2. User reviews the request and if approved the files will get mounted to the app. Although I have to admit that my understanding of this complex topic is rather low.

…

On Tue, Aug 19, 2025 at 9:09 PM Michaël ***@***.***> wrote: I don't know how people talk about this proposal, but don’t forget that a request can only be made after opening a file via the file chooser or via a file that the app already has access to. In addition, the opening of this file will be indicated in the user interface, while reflecting that the list of requested files follows the opening of a file that contains links to these files. This is not a proposal to request a file at any time. Note that if an app has the ability to acquire arbitrary permissions, especially file permissions, the permission request here might not be presented to the user. — Reply to this email directly, view it on GitHub <#1256 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASERIZ635MZ37IGTL5NGZL3ONY5RAVCNFSM6AAAAACEFMC6E6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJVGYYDQNQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** .com>

[Mikenux]

This is generally what is proposed. I don't know if a token is needed, because the app parses the file and then makes the request (the rest is handled by the portal itself).

It's just that you need to open the file from the file chooser. If the app opens a file from '/.kube/config' without using the file chooser, it should not work. However, I'm not sure it is ok to allow requests in hidden folders and presenting a permission dialog to users for apps that can acquire file permissions as I said above. Otherwise, opening the CRT (KEY) file and using related files (#1290) to open the KEY (CRT) file seems acceptable (although it is preferable to use a credential portal to acquire credentials, it may be acceptable to use the related files if both files conceptually represent a credential).

[ondrejkolin]

In this example it's not a credential. It's just a public certificate that you're sure, who do you talk to. Token enables doing the request only once, that was my initial idea + it's clear what is it related to. Thanks for the clarification. 👌

…

On Tue, Aug 19, 2025, 22:37 Michaël ***@***.***> wrote: This is generally what is proposed. I don't know if a token is needed, because the app parses the file and then makes the request (the rest is handled by the portal itself). It's just that you need to open the file from the file chooser. If the app opens a file from '/.kube/config' without using the file chooser, it should not work. However, I'm not sure it is ok to allow requests in hidden folders and presenting a permission dialog to users for apps that can acquire file permissions as I said above. Otherwise, opening the CRT (KEY) file and using related files (#1290 <#1290>) to open the KEY (CRT) file seems acceptable (although it is preferable to use a credential portal to acquire credentials, it may be acceptable to use the related files if both files conceptually represent a credential). — Reply to this email directly, view it on GitHub <#1256 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASERI2QTNS6MYW5LJJHTQD3OODHXAVCNFSM6AAAAACEFMC6E6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJVGY3TKNA> . You are receiving this because you were mentioned.Message ID: ***@***.*** .com>

[Mikenux]

Token enables doing the request only once

I'm not sure I understand. Why only once? Relative to what? I allow multiple requests. The request is only allowed after a file has been opened by the file chooser or after the app used the open-fileset method. Also, the request must be made each time for the portal to check for new files that were not added by the app opening the file. Is there something I missed?

In this example it's not a credential. It's just a public certificate that you're sure, who do you talk to.

Can't all forms of authentication and identity verification (human or object) be grouped together? That said, I don't use this sort of thing, except passwords and my eID card. If these are part of one group, then we could have a system app that collects credentials and certificates. The user can then name them (if they are standard files, the application can certainly read them to help the user knows what they correspond to). Then any app can request credentials or certificates, and the user can select the ones they think are relevant.