You’re going to run “xy” application with exec command “zy”

This icon is not marked as an executable program.

If you created this shortcut, click “Make Service Executable
and Continue”. Otherwise, click “Cancel” as it is likely
a malicious program.

The problem is that at the moment they are not required to be executable. So people have existing .desktop files that are not executable which currently work.

If you suddenly require that they are executable, you will break people’s existing environments. This is bad.

Sorry if I’m asking a stupid question but I’d really like to understand.

Thanks,
Afief

I don’t think I’ve ever seen any linux software offer to chmod+x things and its for a very good reason. You’re better off with the rare occurance of users not being able to run some shortcuts (this is going to be very rare as only powerusers are going to be playing with custom .desktop files) than opening up a huge attack vector that plagues Windows.

Seriously, you really need to consider this more IMO. Having some bullet points and some nicely worded buttons is not going to discourage people who click on random email attachments. Having to save/right-click/click a tab/click a specific checkbox etc. requires some knowledge and perseverance which is good at stopping naive users.

If you pay attention to warning messages, hold ctrl+meta+r and hit Home three times. Do not press either of the buttons below

OK Cancel

And if the user presses either of the buttons then KDE knows they are dealing with someone who doesn’t pay attention and changes the system appropriately.

Yeah, it isn’t actually a very good idea but it would be pretty funny to see.

- I am just as opposed to dialogs as the rest of you, trust me. I’d be much happier simply picking “the right thing” to do in code and having it done, as then I wouldn’t be having to write user-visible text. The problem is that there really are two valid choices here, the user thought they were running a program (i.e. desktop shortcut), or that the user had no idea they were running a program (i.e. OPEN THIS EMAIL!!). One the user chooses to run, the .desktop file is “fixed” and they’ll never receive the prompt again. If the user chooses to Cancel I can’t simply “neuter” the file to remove the dialog because the user may have just then decided that they know it’s a program but they didn’t feel like running it.

- Thiago recommended adding a description of what’s being executed. I actually have added “details text” with that so KMessageBox is supposed to create a Details >> button with it, but that doesn’t happen. I’m still looking into it, but I agree we should do that too.

- I like asd’s “bullet format”, I may re-do it that way even at the expense of space.

- Lots of people have suggested upgrade scripts so that we don’t have to allow situations where we launch a desktop file without +x permission. I suggested that too at first, but unless you spend the amount of time to search all of $HOME you may miss some scripts in use and more dangerously, what if the user has already downloaded a trojan to their Desktop? Adding +x would be incredibly hurtful in that situation. And if you do search all of $HOME, that would take forever to complete.

- People are wary of allowing “known services” to run but the fact of the matter is that the three locations checked contain actual programs by definition. For the vast majority of people this rule won’t matter since the “known service” will be owned by root and therefore already have an exception. This exception is to allow for KDE installations by single user or shared with a non-root owner. The alternative is that all of your commands in the kickoff or old-style K menu, and most of the commands accessible via KRunner stop working or require that nasty UAC-style prompt.

Another thing to keep in mind is that once you’re assuming that the user can be fooled into saving a file deep into say, $HOME/kde-4/share/applications/kde4, you may as well assume that the user can be easily fooled into right clicking that desktop file and checking the “Is executable” checkbox. Allowing only executable files to run is a safety measure to avoid the user accidentally run a program when they were trying to open a file in a editor to see what it was, or to avoid running a attachment they happened to save to their desktop.

Once you start assuming that the user will start following instructions from the attacker as well, they are already 0wned. ;)

New .desktop file creations and new KDE installations will have executable .desktop files where necessary, the prompt is to allow for users to have a chance at using their old shortcuts without too much pain, and will only show up once for each shortcut. By the time 4.4 rolls around a user should probably never have to see the dialog again (at which time perhaps we’ll remove it and make users click that check box themselves) ;)