------=_Part_8221_13418412.1373194751294
Content-Type: text/plain; charset=ISO-8859-1

I was surprised when I looked at the file system proposal and found
unique_path.

unique_path is similar to the POSIX tempnam[1] function that was marked as
obsolecent in POSIX 2008 and tmpfile, mkdtemp and mkstemp recommended in
it's place. Why incorporate the mistakes from posix in C++?

The problem with unique_path is that there is a window of opportunity
between the check that the path name is unique and the time when it is used.
That window can be used by malware -- and in the case of tempnam it have
been used by malware.

I thus propose that 15.38 is removed.

/MF

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



------=_Part_8221_13418412.1373194751294
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I was surprised when I looked at the file system proposal and found unique_=
path.<br><br>unique_path is similar to the POSIX tempnam[1] function that w=
as marked as obsolecent in POSIX 2008 and tmpfile, mkdtemp and mkstemp reco=
mmended in it's place. Why incorporate the mistakes from posix in C++?<br><=
br>The problem with unique_path is that there is a window of opportunity be=
tween the check that the path name is unique and the time when it is used.<=
br>That window can be used by malware -- and in the case of tempnam it have=
 been used by malware.<br><br>I thus propose that 15.38 is removed.<br><br>=
/MF<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_8221_13418412.1373194751294--

.

--047d7b6da616f243fe04e0e9f600
Content-Type: text/plain; charset=ISO-8859-1

On 7 July 2013 13:59, <magfr@lysator.liu.se> wrote:

> I was surprised when I looked at the file system proposal and found
> unique_path.
>
> unique_path is similar to the POSIX tempnam[1] function that was marked as
> obsolecent in POSIX 2008 and tmpfile, mkdtemp and mkstemp recommended in
> it's place. Why incorporate the mistakes from posix in C++?
>
> The problem with unique_path is that there is a window of opportunity
> between the check that the path name is unique and the time when it is used.
> That window can be used by malware -- and in the case of tempnam it have
> been used by malware.
>
> I thus propose that 15.38 is removed.
>
>
This is a known issue, but the current plan is to include unique_path and
document the race possibility.
That means that users need to be careful where and when to use unique_path.
The function itself
is still useful, but it can't be used under the circumstances under which
tmpnam() is unsafe.

Having a mkstemp/mkdtemp equivalent is something that should probably be
handled in subsequent
revisions of the filesystem library.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



--047d7b6da616f243fe04e0e9f600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 July 2013 13:59,  <span dir=3D"ltr">&lt;<a href=3D"mailto:magf=
r@lysator.liu.se" target=3D"_blank">magfr@lysator.liu.se</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
I was surprised when I looked at the file system proposal and found unique_=
path.<br><br>unique_path is similar to the POSIX tempnam[1] function that w=
as marked as obsolecent in POSIX 2008 and tmpfile, mkdtemp and mkstemp reco=
mmended in it&#39;s place. Why incorporate the mistakes from posix in C++?<=
br>
<br>The problem with unique_path is that there is a window of opportunity b=
etween the check that the path name is unique and the time when it is used.=
<br>That window can be used by malware -- and in the case of tempnam it hav=
e been used by malware.<br>
<br>I thus propose that 15.38 is removed.<span class=3D"HOEnZb"><font color=
=3D"#888888"><br><br></font></span></blockquote><div><br></div><div>This is=
 a known issue, but the current plan is to include unique_path and document=
 the race possibility.<br>
</div><div>That means that users need to be careful where and when to use u=
nique_path. The function itself<br>is still useful, but it can&#39;t be use=
d under the circumstances under which tmpnam() is unsafe.<br><br></div>
<div>Having a mkstemp/mkdtemp equivalent is something that should probably =
be handled in subsequent<br></div><div>revisions of the filesystem library.=
 <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6da616f243fe04e0e9f600--

.

------=_Part_1119_32375900.1373240454621
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



2013. j=FAlius 7., vas=E1rnap 12:59:11 UTC+2 id=F5pontban ma...@lysator.liu=
..se a=20
k=F6vetkez=F5t =EDrta:
>
> I was surprised when I looked at the file system proposal and found=20
> unique_path.
>
> unique_path is similar to the POSIX tempnam[1] function that was marked a=
s=20
> obsolecent in POSIX 2008 and tmpfile, mkdtemp and mkstemp recommended in=
=20
> it's place. Why incorporate the mistakes from posix in C++?
>
> The problem with unique_path is that there is a window of opportunity=20
> between the check that the path name is unique and the time when it is us=
ed.
> That window can be used by malware -- and in the case of tempnam it have=
=20
> been used by malware.
>
> I thus propose that 15.38 is removed.
>
> /MF
>

Unlike tmpnam, what is part of C's <stdio.h> (thus, part of C++'s <cstdio>=
=20
as well), unique_path does not check the filesystem for existence of the=20
file (at least that's how I understand the comment about randomness); it=20
just generates a random string based on a template. One can argue that this=
=20
simple functionality is not affected by the error: the existence check is=
=20
delayed to creation.

However, you are right that a temp file name can be used for nothing else=
=20
than.. creating a temp file with that name, so this function is useless=20
alone. Thus I think it would be better if there would be a create_temp_file=
=20
function that gets the same parameters, creates the appropriate temporary=
=20
file and returns an fstream to it..

The function is useful for generating random strings based on a template=20
(like, generating a UUID), but it's quite awkward to have such=20
functionality in a filesystem library..

Regards, Robert

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



------=_Part_1119_32375900.1373240454621
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>2013. j=FAlius 7., vas=E1rnap 12:59:11 UTC+2 id=F5pontban ma...@lys=
ator.liu.se a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">I was surprised when I looked at the file system proposal and found u=
nique_path.<br><br>unique_path is similar to the POSIX tempnam[1] function =
that was marked as obsolecent in POSIX 2008 and tmpfile, mkdtemp and mkstem=
p recommended in it's place. Why incorporate the mistakes from posix in C++=
?<br><br>The problem with unique_path is that there is a window of opportun=
ity between the check that the path name is unique and the time when it is =
used.<br>That window can be used by malware -- and in the case of tempnam i=
t have been used by malware.<br><br>I thus propose that 15.38 is removed.<b=
r><br>/MF<br></blockquote><div><br>Unlike tmpnam, what is part of C's &lt;s=
tdio.h&gt; (thus, part of C++'s &lt;cstdio&gt; as well), unique_path does n=
ot check the filesystem for existence of the file (at least that's how I un=
derstand the comment about randomness); it just generates a random string b=
ased on a template. One can argue that this simple functionality is not aff=
ected by the error: the existence check is delayed to creation.<br><br>Howe=
ver, you are right that a temp file name can be used for nothing else than.=
.. creating a temp file with that name, so this function is useless alone. T=
hus I think it would be better if there would be a create_temp_file functio=
n that gets the same parameters, creates the appropriate temporary file and=
 returns an fstream to it..<br><br>The function is useful for generating ra=
ndom strings based on a template (like, generating a UUID), but it's quite =
awkward to have such functionality in a filesystem library..<br><br>Regards=
, Robert<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1119_32375900.1373240454621--

.

------=_Part_8950_12213373.1373267550885
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On Monday, July 8, 2013 1:40:54 AM UTC+2, R=F3bert D=E1vid wrote:
>
>
>
> 2013. j=FAlius 7., vas=E1rnap 12:59:11 UTC+2 id=F5pontban ma...@lysator.l=
iu.sea k=F6vetkez=F5t =EDrta:
>>
>> I was surprised when I looked at the file system proposal and found=20
>> unique_path.
>>
>> unique_path is similar to the POSIX tempnam[1] function that was marked=
=20
>> as obsolecent in POSIX 2008 and tmpfile, mkdtemp and mkstemp recommended=
 in=20
>> it's place. Why incorporate the mistakes from posix in C++?
>>
>> The problem with unique_path is that there is a window of opportunity=20
>> between the check that the path name is unique and the time when it is u=
sed.
>> That window can be used by malware -- and in the case of tempnam it have=
=20
>> been used by malware.
>>
>> I thus propose that 15.38 is removed.
>>
>> /MF
>>
>
> Unlike tmpnam, what is part of C's <stdio.h> (thus, part of C++'s <cstdio=
>=20
> as well), unique_path does not check the filesystem for existence of the=
=20
> file (at least that's how I understand the comment about randomness); it=
=20
> just generates a random string based on a template. One can argue that th=
is=20
> simple functionality is not affected by the error: the existence check is=
=20
> delayed to creation.
>

I agree that if this is the case then it isn't affected by the error, but=
=20
if that is the case then the function name is misleading and should be=20
something like "random_path" in order to not suggest that the path is=20
checked for uniqueness.
=20

> However, you are right that a temp file name can be used for nothing else=
=20
> than.. creating a temp file with that name, so this function is useless=
=20
> alone. Thus I think it would be better if there would be a create_temp_fi=
le=20
> function that gets the same parameters, creates the appropriate temporary=
=20
> file and returns an fstream to it..
>

Here I disagree - it could be used to create any file system entity, like a=
=20
file, a directory, a named pipe or something else.

The function is useful for generating random strings based on a template=20
> (like, generating a UUID), but it's quite awkward to have such=20
> functionality in a filesystem library..
>

I also have a gut feeling that this represents a more basic algorithm that=
=20
struggles to get out but I have no proposal on that.

/MF

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



------=_Part_8950_12213373.1373267550885
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On Monday, July 8, 2013 1:40:54 AM UTC+2, R=F3bert D=E1vid wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><br><br>2013. j=FAlius 7., vas=E1rnap 12=
:59:11 UTC+2 id=F5pontban <a>ma...@lysator.liu.se</a> a k=F6vetkez=F5t =EDr=
ta:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">I was surprised when I looked at=
 the file system proposal and found unique_path.<br><br>unique_path is simi=
lar to the POSIX tempnam[1] function that was marked as obsolecent in POSIX=
 2008 and tmpfile, mkdtemp and mkstemp recommended in it's place. Why incor=
porate the mistakes from posix in C++?<br><br>The problem with unique_path =
is that there is a window of opportunity between the check that the path na=
me is unique and the time when it is used.<br>That window can be used by ma=
lware -- and in the case of tempnam it have been used by malware.<br><br>I =
thus propose that 15.38 is removed.<br><br>/MF<br></blockquote><div><br>Unl=
ike tmpnam, what is part of C's &lt;stdio.h&gt; (thus, part of C++'s &lt;cs=
tdio&gt; as well), unique_path does not check the filesystem for existence =
of the file (at least that's how I understand the comment about randomness)=
; it just generates a random string based on a template. One can argue that=
 this simple functionality is not affected by the error: the existence chec=
k is delayed to creation.</div></blockquote><div><br>I agree that if this i=
s the case then it isn't affected by the error, but if that is the case the=
n the function name is misleading and should be something like "random_path=
" in order to not suggest that the path is checked for uniqueness.<br>&nbsp=
;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>However, you a=
re right that a temp file name can be used for nothing else than.. creating=
 a temp file with that name, so this function is useless alone. Thus I thin=
k it would be better if there would be a create_temp_file function that get=
s the same parameters, creates the appropriate temporary file and returns a=
n fstream to it..<br></div></blockquote><div><br>Here I disagree - it could=
 be used to create any file system entity, like a file, a directory, a name=
d pipe or something else.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div>The function is useful for generating random strings based on=
 a template (like, generating a UUID), but it's quite awkward to have such =
functionality in a filesystem library..<br></div></blockquote><div><br>I al=
so have a gut feeling that this represents a more basic algorithm that stru=
ggles to get out but I have no proposal on that.<br><br>/MF<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_8950_12213373.1373267550885--

.

------=_Part_371_5478543.1373375669179
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, July 8, 2013 9:12:30 AM UTC+2, ma...@lysator.liu.se wrote:

> On Monday, July 8, 2013 1:40:54 AM UTC+2, R=F3bert D=E1vid wrote:
>>
>>
>> The function is useful for generating random strings based on a template=
=20
>> (like, generating a UUID), but it's quite awkward to have such=20
>> functionality in a filesystem library..
>>
>
> I also have a gut feeling that this represents a more basic algorithm tha=
t=20
> struggles to get out but I have no proposal on that.
>
>
Interesting thing: aside from various references to the values created by=
=20
<random>'s distributions as "numbers", nothing in the formal concept=20
prevents a distribution's result_type from being std::string. Therefore,=20
this basic algorithm is pretty much a string_pattern_distribution where the=
=20
pattern is the param_type.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



------=_Part_371_5478543.1373375669179
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, July 8, 2013 9:12:30 AM UTC+2, ma...@lysator.liu.se wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Monday, July 8, 2013 1:40:54 =
AM UTC+2, R=F3bert D=E1vid wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><b=
r></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The function is=
 useful for generating random strings based on a template (like, generating=
 a UUID), but it's quite awkward to have such functionality in a filesystem=
 library..<br></div></blockquote><div><br>I also have a gut feeling that th=
is represents a more basic algorithm that struggles to get out but I have n=
o proposal on that.<br><br></div></blockquote><div><br></div><div>Interesti=
ng thing: aside from various references to the values created by &lt;random=
&gt;'s distributions as "numbers", nothing in the formal concept prevents a=
 distribution's result_type from being std::string. Therefore, this basic a=
lgorithm is pretty much a string_pattern_distribution where the pattern is =
the param_type.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_371_5478543.1373375669179--

.