Insecure temporary directory creation #85

Closed
opened 2021-12-02 13:13:29 +01:00 by hege-li · 7 comments

Creating predictably named directories/files is insecure and bad practise.

/tmp/tmp-py3-validate-email-UID

Please use something like tempfile.mkdtemp().

Also forcibly running the updater any time loading the module is iffy. Could you atleast use some environment variable or other method that can prevent doing that, for those that have no use for the blacklisting feature?

Creating predictably named directories/files is insecure and bad practise. /tmp/tmp-py3-validate-email-UID Please use something like tempfile.mkdtemp(). Also forcibly running the updater any time loading the module is iffy. Could you atleast use some environment variable or other method that can prevent doing that, for those that have no use for the blacklisting feature?
Owner

mkdtemp creates random file/directory names. if you've looked into the code more, you've seen that the goal of creating the predictably named temp directory is to avoid redownloading the blacklist if the etag in the directory matches the one offered for downloading.

the aforementioned environment variable for skipping the download of the blacklist file (and thusly crippling the module somewhat) is doable, but doing the check/download so far didn't cause much trouble for people.

what's your use case?

mkdtemp creates random file/directory names. if you've looked into the code more, you've seen that the goal of creating the predictably named temp directory is to avoid redownloading the blacklist if the etag in the directory matches the one offered for downloading. the aforementioned environment variable for skipping the download of the blacklist file (and thusly crippling the module somewhat) is doable, but doing the check/download so far didn't cause much trouble for people. what's your use case?
Author

Ok, it does seem reasonable.

I'm using "envelope" Python module which indirectly uses validate_email without any blacklisting stuff. So I was wondering why my /tmp gets bombarded with this. I guess it's not resource intensive, but seems unneeded regardless.

I'll atleast set a private TMPDIR for the script then.

Ok, it does seem reasonable. I'm using "envelope" Python module which indirectly uses validate_email without any blacklisting stuff. So I was wondering why my /tmp gets bombarded with this. I guess it's not resource intensive, but seems unneeded regardless. I'll atleast set a private TMPDIR for the script then.
Owner

what I can do for you (and what seems reasonable), is to use two environment variables, one to disable the updater/downloader, and another to tell it where to put its directory and files.

would that be a solution for you?

what I can do for you (and what seems reasonable), is to use two environment variables, one to disable the updater/downloader, and another to tell it where to put its directory and files. would that be a solution for you?
Author

Yes that sounds good, I think envelope-module devs could use it too so users don't have to.

Not sure if there's a need for the another (file location) since TMPDIR etc can redirect it somewhere.

Yes that sounds good, I think envelope-module devs could use it too so users don't have to. Not sure if there's a need for the another (file location) since TMPDIR etc can redirect it somewhere.
Owner

1.0.4 is out now, should work unless I forgot something.

You can pass a PY3VE_IGNORE_UPDATER environment variable now to skip the update process on module load (excluding install time).

1.0.4 is out now, should work unless I forgot something. You can pass a `PY3VE_IGNORE_UPDATER` environment variable now to skip the update process on module load (excluding install time).
Author

It does seem to prevent the updating itself, atleast I don't get anymore network exceptions from our closed network..

But I kept wondering why the tmp-directory still exists. Apparently reload_builtin_blacklist() creates the lockfile anyway. Not sure if it has any purpose when loading the static blacklist. And why load the list in memory, if it's not intended to be used..

It does seem to prevent the updating itself, atleast I don't get anymore network exceptions from our closed network.. But I kept wondering why the tmp-directory still exists. Apparently reload_builtin_blacklist() creates the lockfile anyway. Not sure if it has any purpose when loading the static blacklist. And why load the list in memory, if it's not intended to be used..
Owner

Hm, after looking into the module coming from this angle, realized that creating the lockfile isn't necessary for loading the builtin blacklist.txt. The module ships a blacklist in its data directory that is downloaded at the module install time (or in your case, when collecting-the-modules-for-deployment time).

The lockfile was only necessary when an updater process might have been running on module startup, updating the aforementioned text file during its run, in the temp directory.

Thus, 1.0.5 is out now, should fix this.

Hm, after looking into the module coming from this angle, realized that creating the lockfile isn't necessary for loading the builtin blacklist.txt. The module ships a blacklist in its data directory that is downloaded at the module install time (or in your case, when collecting-the-modules-for-deployment time). The lockfile was only necessary when an updater process might have been running on module startup, updating the aforementioned text file during its run, in the temp directory. Thus, 1.0.5 is out now, should fix this.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: karolyi/py3-validate-email#85
No description provided.