We need to talk about $HOME/.local/share/applications

Kyuyrii · January 22, 2026, 8:23pm

https://www.youtube.com/watch?v=UVh--plT08s&feature=youtu.be

I apologize if mentioning you in posts is problematic, but it’s truly necessary that you see this.

I’ve seen discussions about accessing the applications folder, about malicious .desktop files being created to bypass Snap’s confinement.

But that involved the personal-files interface, which I thought was the only way to access the applications folder.

But now I discover that no, it wasn’t the only way.

I downloaded menukaran, disconnected the plugin that allows reading the $HOME/.local/share/applications folder, and tried creating a .desktop file in it, and it worked.

It’s possible to create .desktop files in the applications folder without using the personal-files interface, using (if I’m not mistaken) the XDG Desktop Portal. Basically, it’s pointless to prevent apps from accessing the applications folder in the conventional way if malicious apps can use the XDG Desktop Portal to do so.

It’s a senseless situation.

If security is important, what needs to be done is to contact the desktop environment developers so that they can modify the application menus to better differentiate between .desktop files; otherwise, the problem will never be solved.

jslarraz · January 23, 2026, 10:14am

Hey @Kyuyrii

Basically, it’s pointless to prevent apps from accessing the applications folder in the conventional way if malicious apps can use the XDG Desktop Portal to do so.

It’s a senseless situation.

I’m sorry, but I don’t think it is senseless. Unless I’m missing something, your video shows that when using portals, the user needs to explicitly accept the creation or modification of each .desktop file.

On the other hand, the personal-files interface grants the application the ability to create and modify arbitrary files at any time, without even notifying the user. Thus, I think these two scenarios are very different from the security perspective.

That said, I think that ideally creation of .desktop files should only be possible via a sandbox specific API.

Kyuyrii · January 23, 2026, 12:11pm

@jslarraz

Apparently you’ve never tested the limits of this.

https://youtu.be/vvn2JHEiDTs?si=5lsQzgpn3m5oqiOs

Watch this video, I modified the Zordeer code to use the XDG Desktop Portal to create .desktop files. I created 20 .desktop files at once; the file selector didn’t specify the names of the files that would be created, nor did it specify the quantity.

If an app wants to create malicious .desktop files, they can. Regardless of whether or not they have access to personal-files.

It could be during the creation of a .desktop file that the user actually wants to create, like a shortcut to a game, or it could be a .desktop file that the app recommends creating to circumvent Snap limitations, instead of prompting the user to connect the necessary plugs.

They could even create a .desktop file in the Desktop folder that executes a script that generates malicious .desktop files in the applications folder.

All this security around the personal-files plug doesn’t make sense when it involves apps that aren’t malicious, because malicious apps won’t even request a connection to the personal-files plug, precisely so that those in charge of security don’t even know they’re accessing the applications folder.

jslarraz · January 23, 2026, 1:17pm

Apparently you’ve never tested the limits of this.

You are right

Watch this video, I modified the Zordeer code to use the XDG Desktop Portal to create .desktop files. I created 20 .desktop files at once; the file selector didn’t specify the names of the files that would be created, nor did it specify the quantity.

Fine, but the user still needs to actively approve the creation, which is not the case when using the personal-files interface.

If an app wants to create malicious .desktop files, they can. Regardless of whether or not they have access to personal-files.

It could be during the creation of a .desktop file that the user actually wants to create, like a shortcut to a game, or it could be a .desktop file that the app recommends creating to circumvent Snap limitations, instead of prompting the user to connect the necessary plugs.

Yes, upon user approval.

Even if the portal were to deny the creation of files in this directory, you could still prompt the user to run cp ~/*.desktop ~/.local/share/applications.

I think it is somehow similar to sudo. Users can use sudo to run applications with elevated privileges if they want. However, that doesn’t mean that applications should be able to elevate privileges themself (in general terms), without any consent from the user or even notifying them.

Kyuyrii · January 23, 2026, 2:27pm

Non-malicious apps that need access to the applications folder are harmed because of this.

Malicious apps that want to create malicious .desktop files can still do so, either in the Desktop folder or via the XDG Desktop Portal. Even if the user needs to confirm the creation, they cannot see which .desktop files will be created.

I just showed you that it’s possible to create 20 .desktop files while the user might think only 1 is being created.

So while the user creates 1 normal .desktop file, the malicious app could be creating dozens of .desktop files that will deceive the user.

Or simply a .desktop file that will cause an app outside the confines of Snap to open.

And another thing that doesn’t make much sense is that it’s dangerous to access the applications folder because of the .desktop files, but what about the $HOME folder?

Users may have several sensitive files stored in the $HOME folder, especially those users who do not have an extra SSD/HDD. I know you care about security, but the way things are currently, what’s being generated isn’t security, it’s limitation.

Like the joystick plug issue, users not being able to use the gamepad in emulators and game launchers is like downloading a text editor and not being able to type with the keyboard.

I thought the requests were about a vote of confidence from the reviews for the developers, but if there’s no trust, the user experience will be harmed, the developers will be frustrated and consequently won’t want to support Snap/Snapd/Snapcraft.

And there’s an important detail, you said “Yes, upon user approval.”

Users also approve the installation of Snap apps; they even need to enter the password for the installation to happen.

When installing a Snap app and opening it, the user is already trusting that the Snap app won’t do anything bad to the files the app can access and the information the user enters.

For example, Minigalaxy, a launcher for GOG games, requires the user to enter their email and password to log into their GOG account. If Minigalaxy were to do something malicious, it wouldn’t even need access to the $HOME folder, applications, or access to the joystick plug.

Kyuyrii · January 23, 2026, 7:07pm

I discovered something interesting; I don’t know if it’s a bug or a function of the XDG Desktop Portal. I really need you to see this video.

https://youtu.be/HXkhI1x_WTo?si=dWweLCZlkXBYLfkp

If Zordeer considers $HOME/.local/share/applications as the menu_dir folder and tries to create the .desktop files, nothing happens due to lack of access. This is expected.

However, if I click on the option to choose where the menu folder will be, the system file selector appears, and upon confirming that I want to use the $HOME/.local/share/applications folder, the saved location is /run/user/1000/doc/614b0d0d/applications.

This changes a lot; after Zordeer gained access to the $HOME/.local/share/applications folder via the XDG Desktop Portal, it gained read and write access to the $HOME/.local/share/applications folder without needing the personal-files interface. Basically, the user doesn’t even need to try creating a .desktop file; just confirming the location of the $HOME/.local/share/applications folder gives the app free access to it. They won’t even need to open the file selector again.

I restarted my device and access to the $HOME/.local/share/applications folder wasn’t revoked. I have no idea if the access granted by the XDG Desktop Portal has an expiration time or not.

Kyuyrii · January 24, 2026, 11:51am

I just did another test, I modified Zordeer so that it uses the .config and .local folders as the basis for creating files.

https://youtu.be/sQFVtHR3Evc?si=EEElOWCTU4u6X-yD

By selecting the .config and .local folders through the XDG Desktop Portal, Zordeer was able to create the folders, subfolders, and the .desktop, .menu, and .directory files without problems, and of course, read what already exists.

What Snap does is apparently designed for what existed before the XDG Desktop Portal, for example, Transmission GTK. I remember seeing it using its own file selector, and because of that, it could only access what Snap allowed.

However, now with the XDG Desktop Portal, Snap’s attempt to prevent access to hidden folders doesn’t work completely.

If a trustworthy app wants access to certain folders via personal-files (like emulators and game launchers), it’s extremely difficult to achieve. They might use the XDG Desktop Portal, but they would need to modify the app’s code, making something basic more complicated for developers and users.

Meanwhile, malicious apps can bypass personal-files, writing their code with the intention of using the XDG Desktop Portal, precisely expecting the user to grant access to the folders the malicious app wants to access.

And it wouldn’t be very strange for an app to request access to the .config and .local folders, since these are common folders used by native apps and AppImages.

Basically, normalizing the use of the XDG Desktop Portal to grant access to hidden folders creates an absurdly bigger security problem than allowing more apps to access hidden folders using the personal-files interface.

If users find it normal to grant access to hidden folders via the XDG Desktop Portal, it will create many opportunities for malicious apps to exploit this.

However, if the personal-files plug is given to trusted apps, users will be suspicious when an app requests access to a hidden folder via the XDG Desktop Portal instead of already having access to it.

ogra · January 26, 2026, 2:09pm

See, the problem here is that by default all apps are considered potentially malicious in the strict snap world and should only talk to the outside world via mediated interfaces … in case that is not possible (like with docker or the steam snap) there exist app specific interfaces that are exclusively designed only for that particular app and an additional trust level is needed by vetting the publisher (in case of both snaps above only Canonical can upload them)…

The thing you want to achieve would need an interface that mediates the access to that location (i.e. it might use a particular formatted file the snap ships that snapd reads and mediates to then create a .desktop file dynamically based on verified values from that file defined in the snap) …