[Kbabel] bugfix for KBabel

[Nicolas Goutte]

On Thursday 01 September 2005 03:25, Jens Herden wrote:
> > Unlinking the KTempfile is not much secure.
>
> What does this mean? Why is it not secure or why is it less secure than the
> old version?

The problem of unlinking is multiple and especially of two kinds:
- first the library might reassign the same number for the temp file, as temp 
file names are basically a number. (That should not happen but who knows.) As 
long as the temp file exists, it can be tested. If you unlink it, it does not 
exist anymore, so it could be assumed that the number is free and therefore 
could be re-assigned. (And if two applications would use the same temp file, 
there would be probably some data lost.)

- second, you create the file with read and write rights only for the user. If 
you unlink the file, you open a gap for an attacker to place its file/link in 
place instead, where the attacker can control the access rights.

It is the second reason why KTempFile is so complex and has member functions 
to so many classes and types of files. (That is also why $KDETEMP defaults to 
a directory only owned by the user, so that an attacker cannot create a 
file.)

You can also read the Doxygen documentation of KTempFile::name which asks to 
avoid using only the name of the KTempFile.

>
> > I think the real solution would be to use something else than
> > KMimeType::findByURL
>
> How? The file is not written to the disk yet, so we can not analyse the
> content.

For example, the file was read once (as KBabel cannot create new files).

> Can we use KMimeType::findByURL on the url that is in the private data?
> Then I would not need to pass the url as parameter at all and the filename
> of the temp file would not be important.

You seems to have found the answer yourself . ;-)

>
> Jens

Have a nice day!