[Kbabel] bugfix for KBabel

Jens Herden jens at kdewebdev.org
Thu Sep 1 16:07:14 CEST 2005


Hello Nicolas,

> > > 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 did read it but I did not understand it. Your remarks make it more clear to 
me, thanks for this.


> > > 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 . ;-)

:-)

So shall I commit the patch then?

Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kbabel/attachments/20050901/fdbe7d53/attachment.pgp


More information about the kbabel mailing list