Csound Csound-dev Csound-tekno Search About

[Cs-dev] The use of tmpnam is dangerous

Date2008-12-30 16:32
FromFelipe Sateler
Subject[Cs-dev] The use of tmpnam is dangerous
AttachmentsNone  None  None  

Date2008-12-30 16:40
Fromjpff@cs.bath.ac.uk
SubjectRe: [Cs-dev] The use of tmpnam is dangerous
But mktemp does not do the same thing; it creates the file, and the manual
does not say that oit tells oine the name either.
==JOhn ff

> This is a warning I get from gcc when compiling csound, and after reading
> the
> manpage of that function, I agree. tmpnam returns a string that is
> guaranteed
> to not be the name of an existing filename... but this is only at the time
> of
> the calling. In the time between the call to tmpnam and fopen, an attacker
> could create a symlink with that name, and destroy data that it would not
> have been able to otherwise.
> In linux, this is easily solvable by replacing the tmpnam call with
> mkstemp,
> but I'm not sure if there is an equivalent call for OSX or Windows. The
> function is POSIX, so I'm guessing OSX should have it, and probably
> Windows
> in some sort of compatibility layer. Can anyone confirm?
>
> Saludos,
> Felipe Sateler
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2008-12-30 17:04
FromFelipe Sateler
SubjectRe: [Cs-dev] The use of tmpnam is dangerous
AttachmentsNone  None  None  

Date2008-12-31 07:06
Fromjpff
SubjectRe: [Cs-dev] The use of tmpnam is dangerous
I still do not see how this helps.

Suppose I define mytmpnam to call mkstemp and collect the name, the
file is open, and so before I can use it it needs to me closed.  If it
is closed then it can be captured.  If it is not closed then there are
internal problems
  And ... I read the manual page of mkstemp again and it is still not
clear to me that the name is returned; that is not stated in the
return values
  So, please explain slowly
==John ffitch

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2008-12-31 07:28
FromFelipe Sateler
SubjectRe: [Cs-dev] The use of tmpnam is dangerous
AttachmentsNone  None  None  

Date2008-12-31 08:08
Fromjpff
SubjectRe: [Cs-dev] The use of tmpnam is dangerous
I have been looking more closely and it is all fake.  The filename
from tmpnam is not used directly anyway, and the use of mkstemp does
not allow for an extension.  The code starts from the result of tmpnam
and constructs a file name which is then checked for existence.  I
cannot see what mkstemp does better than that.  All because gcc
produces an incorrect warning!
==John ffitch

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2008-12-31 10:52
FromFelipe Sateler
SubjectRe: [Cs-dev] The use of tmpnam is dangerous
AttachmentsNone  None  None  

Date2008-12-31 11:55
Fromjpff
SubjectRe: [Cs-dev] The use of tmpnam is dangerous
But as I said, if you close the file the same could happen, and anyway
csound does not use the name of a file created by tmpnam or a file
created by mkstemp.  I also repeat, mkstemp does not allow for an
extension to the name.  I could do a total rewrite in this area, but
the tmpnam is as secure/insecure as the version with mkstemp
==John ffitch

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2009-01-04 20:53
FromFelipe Sateler
SubjectRe: [Cs-dev] The use of tmpnam is dangerous
AttachmentsNone  None  None