220 5329 <49ba4bb5-ded5-4d57-9365-8372d631713f@isocpp.org> article Path: news.gmane.org!not-for-mail From: magfr@lysator.liu.se Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Remove filesystem unique_path Date: Mon, 8 Jul 2013 00:12:30 -0700 (PDT) Lines: 152 Approved: news@gmane.org Message-ID: <49ba4bb5-ded5-4d57-9365-8372d631713f@isocpp.org> References: <4b95e9b9-d5cc-4314-bd32-1e09fe35ed9d@isocpp.org> <8687c067-2ff2-4fcd-a9f6-3b896d4c0d12@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8950_12213373.1373267550885" X-Trace: ger.gmane.org 1373267552 2707 80.91.229.3 (8 Jul 2013 07:12:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Jul 2013 07:12:32 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELLREETMBRBX6M5GHAKGQEQY4KLJI@isocpp.org Mon Jul 08 09:12:34 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f69.google.com ([209.85.213.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uw5cf-0005SO-B2 for gclcip-std-proposals@m.gmane.org; Mon, 08 Jul 2013 09:12:33 +0200 Original-Received: by mail-yh0-f69.google.com with SMTP id b12sf5490019yha.8 for ; Mon, 08 Jul 2013 00:12:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=kZM0inYNEViza03bVhDOQiHswlphSG8/uPvdNJxoJb4=; b=VIOXtERb9qztRglkoHvXkMyKXdUdX+1CD/3DWqcj7CQMYPJgNp8oSyt69VyPwNkelD 2URy8BoOZFAa39ZizTuhaWHM4vvzMpQieHJraFQPg9mdJq/fWQeOxd/9xYbCJmQc0oI4 7GISRDRu5AYT71DWCoX2VVIwi/OAH1OvuavyQrLAMWG/QCSyR5Jrrrmj9v3t+zIDsK1G GfnJWZk5aeb5aKh4xlIhhcLsE5LEMtztgkroMIhypKrWAXdo8c30vhPuW3rVL6gKLQZM 4sDlN1DVTK7belhxMdEgCjh1L/BAn/f5znFfrJj/lHENx9ky2BuQWGLWr3jAxqz2Adn7 C7ow== X-Received: by 10.236.125.200 with SMTP id z48mr10952340yhh.55.1373267552365; Mon, 08 Jul 2013 00:12:32 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.120.234 with SMTP id lf10ls1634246qeb.49.gmail; Mon, 08 Jul 2013 00:12:31 -0700 (PDT) X-Received: by 10.49.101.78 with SMTP id fe14mr467770qeb.13.1373267551180; Mon, 08 Jul 2013 00:12:31 -0700 (PDT) In-Reply-To: <8687c067-2ff2-4fcd-a9f6-3b896d4c0d12@isocpp.org> X-Original-Sender: magfr@lysator.liu.se Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5329 Archived-At: ------=_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 (thus, part of C++'s =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:

2013. j=FAlius 7., vas=E1rnap 12= :59:11 UTC+2 id=F5pontban ma...@lysator.liu.se a k=F6vetkez=F5t =EDr= ta:
I was surprised when I looked at= the file system proposal and found unique_path.

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++?

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.
That window can be used by ma= lware -- and in the case of tempnam it have been used by malware.

I = thus propose that 15.38 is removed.

/MF

Unl= ike tmpnam, what is part of C's <stdio.h> (thus, part of C++'s <cs= tdio> 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.

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

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.

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

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.

/MF

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;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-proposals/<= /a>.
 
 
------=_Part_8950_12213373.1373267550885-- .