Re: [kde-linux] KDESU doesn't work again with 4.10
- Date: Fri, 24 May 2013 03:37:08 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] KDESU doesn't work again with 4.10
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 ... /
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.
The top hit here (in case yours is different... watch the link-wrap):
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.
More info: http://www.kde.org/faq.html.