Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #102921 > unrolled thread

Make a unique filesystem path, without creating the file

Back to article view | Back to comp.lang.python

Contents

  Make a unique filesystem path, without creating the file Ben Finney <ben+python@benfinney.id.au> - 2016-02-15 08:46 +1100
    Re: Make a unique filesystem path, without creating the file Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-14 23:48 +0100
    Re: Make a unique filesystem path, without creating the file Grant Edwards <invalid@invalid.invalid> - 2016-02-15 15:46 +0000
    Re: Make a unique filesystem path, without creating the file "Mario R. Osorio" <nimbiotics@gmail.com> - 2016-02-15 20:46 -0800
      Re: Make a unique filesystem path, without creating the file Ben Finney <ben+python@benfinney.id.au> - 2016-02-16 16:03 +1100

#102921 — Make a unique filesystem path, without creating the file

Howdy all,

How should a program generate a unique filesystem path and *not* create
the filesystem entry?

The ‘tempfile.mktemp’ function is strongly deprecated, and rightly so
<URL:https://docs.python.org/3/library/tempfile.html#tempfile.mktemp>
because it leaves the program vulnerable to insecure file creation.

In some code (e.g. unit tests) I am calling ‘tempfile.mktemp’ to
generate a unique path for a filesystem entry that I *do not want* to
exist on the real filesystem. In this case the filesystem security
concerns are irrelevant because there is no file.

The deprecation of that function is a concern still, because I don't
want code that makes every conscientious reader need to decide whether
the code is a problem. Instead the code should avoid rightly-deprecated
APIs.

It is also prone to that API function disappearing at some point in the
future, because it is explicitly and strongly deprecated.

So I agree with the deprecation, but the library doesn't appear to
provide a replacement.

What standard library function should I be using to generate
‘tempfile.mktemp’-like unique paths, and *not* ever create a real file
by that path?

-- 
 \        “If you have the facts on your side, pound the facts. If you |
  `\     have the law on your side, pound the law. If you have neither |
_o__)                       on your side, pound the table.” —anonymous |
Ben Finney

[toc] | [next] | [standalone]

#102922

Ben Finney wrote:

> How should a program generate a unique filesystem path and *not* create
> the filesystem entry?

The Python documentation suggests that it should not.
 
> The ‘tempfile.mktemp’ function is strongly deprecated, and rightly so
> <URL:https://docs.python.org/3/library/tempfile.html#tempfile.mktemp>
> because it leaves the program vulnerable to insecure file creation.
> 
> In some code (e.g. unit tests) I am calling ‘tempfile.mktemp’ to
> generate a unique path for a filesystem entry that I *do not want* to
> exist on the real filesystem. In this case the filesystem security
> concerns are irrelevant because there is no file.

I do not think that you have properly understood the problems with 
tmpfile.mktemp().
 
> […]
> It is also prone to that API function disappearing at some point in the
> future, because it is explicitly and strongly deprecated.
> 
> So I agree with the deprecation, but the library doesn't appear to
> provide a replacement.

| mktemp() usage can be replaced easily with NamedTemporaryFile(), passing 
| it the delete=False parameter: [example]

> What standard library function should I be using to generate
> ‘tempfile.mktemp’-like unique paths, and *not* ever create a real file
> by that path?

I do not think it is possible to avoid the creation of a real file using the 
PSL; in fact, that a file is created appears to be precisely what fixes the 
problems with tempfile.mktemp() because then it cannot happen that someone 
else creates a file with the same name at the same time:

| tempfile.NamedTemporaryFile(mode='w+b', buffering=None, encoding=None, 
| newline=None, suffix=None, prefix=None, dir=None, delete=True)
| 
| This function operates exactly as TemporaryFile() does, except that the 
| file is guaranteed to have a visible name in the file system (on Unix, the 
| directory entry is not unlinked). […] If delete is true (the default), the 
| file is deleted as soon as it is closed. […]

It is of course possible to generate a filename that is not currently used, 
but I am not aware of a PSL feature that does this, and if there were such a 
feature there would be the same problems with it as with mktemp().

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#102969

On 2016-02-14, Ben Finney <ben+python@benfinney.id.au> wrote:
> Howdy all,
>
> How should a program generate a unique filesystem path and *not* create
> the filesystem entry?

Short answer: you can't because it's the filesystem entry operation
that is atomic and guarantees uniqueness.

> [..]

> What standard library function should I be using to generate
> ‘tempfile.mktemp’-like unique paths, and *not* ever create a real file
> by that path?

What's the point of creating a unique path if you don't want to create
the file?

-- 
Grant Edwards               grant.b.edwards        Yow! I'm rated PG-34!!
                                  at               
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#102984

I would create a RAM disk (http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/), generate all the path/files I want with any, or my own algorithm, run the tests, unmount it, destroy it, be happy ... Whats wrong with that?? AFAIK, RAM disks do not get logged, and even if they do, any "insecure" file created would also be gone.



On Sunday, February 14, 2016 at 4:46:42 PM UTC-5, Ben Finney wrote:
> Howdy all,
> 
> How should a program generate a unique filesystem path and *not* create
> the filesystem entry?
> 
> The 'tempfile.mktemp' function is strongly deprecated, and rightly so
> <URL:https://docs.python.org/3/library/tempfile.html#tempfile.mktemp>
> because it leaves the program vulnerable to insecure file creation.
> 
> In some code (e.g. unit tests) I am calling 'tempfile.mktemp' to
> generate a unique path for a filesystem entry that I *do not want* to
> exist on the real filesystem. In this case the filesystem security
> concerns are irrelevant because there is no file.
> 
> The deprecation of that function is a concern still, because I don't
> want code that makes every conscientious reader need to decide whether
> the code is a problem. Instead the code should avoid rightly-deprecated
> APIs.
> 
> It is also prone to that API function disappearing at some point in the
> future, because it is explicitly and strongly deprecated.
> 
> So I agree with the deprecation, but the library doesn't appear to
> provide a replacement.
> 
> What standard library function should I be using to generate
> 'tempfile.mktemp'-like unique paths, and *not* ever create a real file
> by that path?
> 
> -- 
>  \        "If you have the facts on your side, pound the facts. If you |
>   `\     have the law on your side, pound the law. If you have neither |
> _o__)                       on your side, pound the table." --anonymous |
> Ben Finney

[toc] | [prev] | [next] | [standalone]

#102985

"Mario R. Osorio" <nimbiotics@gmail.com> writes:

> I would create a RAM disk
> (http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/),
> generate all the path/files I want with any, or my own algorithm, run
> the tests, unmount it, destroy it, be happy ... Whats wrong with
> that??

It is addressing the problem at a different level. I am not asking about
writing a wrapper around the test suite, I am asking about an API to
generate filesystem paths.

Your solution is a fine response to a different question.

-- 
 \        “Consider the daffodil. And while you're doing that, I'll be |
  `\              over here, looking through your stuff.” —Jack Handey |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web