Bug 149903

Created attachment 21635 [details]
Testcase

Should we really launch /bin/ls when clicking on that symlink? That would
seem like pretty dangerous behavior to me.... Hmm... OK, if I tar xf the tar file
then its ls symlink does point to /bin/ls indeed, not to bin/ls inside the tar file
like I first assumed.

Well I sort of fixed the bug, it now redirects to /bin/ls, but because konq listed it
as a non-executable file in the first place, it's trying to open it with another
application, and since there's no application associated with this type of file,
you get the open with dialog.... Not perfect for this use case, but it means
symlinks to local files that are not executables are fixed, at least.

Is there a real use case for this? Symlinks to executables inside tar files, and launching them from konqueror?
I'm curious -- and unsure about the security implications (what if I name a link "ls" but it in fact calls something
more dangerous... it's easier to click on it by mistake than when typing shell commands...).


Created an attachment (id=21660)
tar.cc.149903.diff

Well, the "use-case" I had was simply having kdevelop3 application templates with symlinks (not sure anymore why). And when the templates are built they are tar'red and the tar is installed. Then later when trying to create a project from the template that doesn't work because KTar can't unpack the symlinks that were tar'red during compilation. So I ended up with no kdevelop project. 

I don't use the symlinks anymore, but still I don't understand why KTar differs from normal tar in that it can't untar symlinks. I also don't quite understand what you said David, i.e. how it works now.

David, thanks for the work so far. I think what you done is sufficient or at least worth a try. I don't know the use case.

Nevertheless I'm wondering why KTar should behave differently than ark. KTar and ark already behave differently WRT directly included executables.

Ah so the bug is about extracting, not about "running" the executable.
Extracting the symlink currently creates a copy of /bin/cp; this is another bug, I'll have to investigate it.

SVN commit 715315 by dfaure:

Fix extraction of symlinks from tar/zip files when using copyTo() - at least at the KArchive level.
Unit tests in trunk.
CCBUG: 149903


 M  +25 -15    karchive.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=715315

On Thursday 20 September 2007, David Faure wrote:
> Extracting the symlink currently creates a copy of /bin/cp; this is another bug, I'll have to investigate it.


Hmm. It's sort of a feature.
See old (closed) bug #5601 -- when copying a file over KIO, and the file is a remote symlink,
KIO resolves the symlink and copies the target file: this is because on FTP we 
want to download the real file, not the symlink.
However I can see how that is unexpected for tar:/...
This probably means that people see a conceptual difference between 
"ftp->file is a download, tar->file is an extraction".
Downloading a link makes no sense, while extracting a link does.
So much for consistency in the KIO operations :-)
Maybe this is something we can do depending on Class=:local and Class=:internet
(we already know if a protocol is local or remote).
So local->local should copy symlinks, while internet->local and internet->internet should copy the actual file, I guess?

FWIW, I can't answer.

I can confirm that this behaviour is still present in 4.1. But what should be the correct one? Is there any consensus?

I am not sure what to do with this bug. I'd propose closing it as WONTFIX, but if somebody does have strong opinions about this behavior we can also move it to kio-extras and keep it open. Is there anyone who opposes closing this report?

I do strongly believe that displaying "tar:/bin/ls" in the error message is inappropriate. If there is a decision to not support symlinks in KTar, there should be a clear message to that effect (and no errors printed in console).

Okay, I'll move this report to kio-extras then.