Bug 461941

Summary: When the user asks to modify a desktop file that's a symlink to one in a non-writable location, make a writable copy of it in place and then modify that
Product: [Frameworks and Libraries] frameworks-kio Reporter: Stefan Hamminga <stefan>
Component: Properties dialogAssignee: KIO Bugs <kio-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: wishlist CC: ashark, kdelibs-bugs, nate, notmart
Priority: NOR Keywords: usability
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Stefan Hamminga 2022-11-17 09:20:45 UTC
SUMMARY

When adding a program to the desktop from the global menu the resulting desktop 'shortcut' is a symlink to the desktop file in /usr. A regular user cannot modify this file so any attempt to set -for example- arguments in the properties menu of the desktop item will result in a permission error.

STEPS TO REPRODUCE

1. Open global menu
2. Locate any application
3. Right-click application entry
4. Click 'Add to Desktop'
5. Right-click new desktop icon
6. Click 'Properties'
7. Click the 'Application' tab
8. Type some argument in the 'Arguments' box
9. Click 'Ok'

OBSERVED RESULT

Pop-up box with an error message stating insufficient write access to `/home/${USER}/Desktop/${application}.desktop` file. (which is actually a symlink).

EXPECTED RESULT

Successfully updating the application properties for _this_ user.

SOFTWARE/OS VERSIONS

Linux/KDE Plasma: 5.26.3
Arch Linux 64-bit as of 2022-11-17

ADDITIONAL INFORMATION

Proposed solutions:

(A) Use an 'overlay' concept similar to how systemd solves this

or

(B) Copy-on-write: As soon as the file is modified create a local copy
Comment 1 Nate Graham 2022-11-29 19:32:03 UTC
I see the problem. The "Add to desktop" menu item creates a symlink to the original file, which typically lives in a system location. When you try to edit the properties of the desktop file in the dialog window, it attempt to write the changes to the original file and fails due to lack of permission.

Probably in this case, when the user attempts to edit a desktop file that's a symlink to a system location, under the hood a copy should be created so that the user is editing something they have access to change.
Comment 2 Andrew Shark 2023-10-25 13:12:01 UTC

*** This bug has been marked as a duplicate of bug 450727 ***