James Tyrer posted on Thu, 23 May 2013 15:28:08 -0700 as excerpted: > Following up on this. I find that there is a great mystery which I > presume is a bug. > > Your 'desktop' file works when it is in a menu. > > Specifically, there is a menu item under System that correctly opens a > filemanager window as root using KDESU. However, if you drag this from > the menu to the DeskTop file and "Copy" then it doesn't work. The KDESU > window pops up and I enter the password correctly, but the filemanager > window NEVER shows up. :-(. > > Thanks again for trying to help. > > So, I guess that I will stick to my work around till somebody fixes what > appears to be a bug.
IIRC/AFAIK it's not a bug, it's a security measure. I'm fuzzy on some of the details but some time in the late kde-3.5 era, shortly before kde4 came out IIRC, there was a big hubbub about the security of *.desktop files located on the desktop. The problem was (IIRC) that *.desktop files, similar to *.lnk aka "shortcut" files in the MS Windows world, are /too/ configurable, allowing the icon and name displayed to have nothing to do with the command actually run, if so configured. Combined that with people often downloading content from untrusted parts of the net directly to the desktop, and it's a recipe for a serious security issue, since at least in theory, wherever they were downloading the file from could say it was for example "The Gimp" and have the appropriate icon for the gimp configured to be displayed, but instead, the actual command run could do something entirely different. This is *PARTICULARLY* a problem with super-user required commands, since then the command could (barring a strict SELinux or the like setup) do literally anything on/to the system, including a rm -rf /, or sfdisk ... / dev/sda, or... So the major desktops (including kde) fixed the security issue by restricting what ordinary *.desktop files could do when they were on the desktop. This is where my understanding goes fuzzy, as I /think/ there's some way to authorize *.desktop files so they still work, that avoids the danger of executing random files that simply happen to be downloaded to the desktop or whatever, but I was never clear on how that all worked to begin with, and of course now, I'm writing from memory about a security issue that surfaced and was fixed several years ago now, so even some of the details I did know are likely gone. But my strategy in such cases is to file away enough information about it in my head to spot the situation should I come across it later, and to google up an answer, should I badly enough need it to work that it's worth the investigation. ... Which seems to be the case here. A quick google turns up some articles on the subject. I didn't refine the google enough to weed out what appear to be a bunch of false positives as well, but at least the top hit seems to apply, and scanning down the list I see at least one more on the first page from about the same time frame (2009) that looks to be related as well. I'll let you read those and then refine the search further and go deeper, if you like. My google: http://www.google.com/search?q=linux+desktop+file+execution+vuln The top hit here (in case yours is different... watch the link-wrap): https://cubist.cs.washington.edu/Security/2009/03/13/linux-desktop- security-vulnerabilities/ Turns out the first thing to check is the executable bit. See if setting that lets it run as expected. (On most desktops the security bit would be reset when dragging/saving the *.desktop file to the desktop, so it couldn't be accidentally clicked to run, without deliberately setting the executable bit, first.) Actually, that makes more sense to me now that when I read about it back then (I think I was missing the fact that the executable bits would be reset by default, so I couldn't see what would stop it from running, or how simply checking the executable bit on the file before allowing it to run could possibly make the difference between a secure solution and an insecure solution). So I'm not so fuzzy on it, any more. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
