duplicity.tempdir module

Provides temporary file handling cenetered around a single top-level securely created temporary directory.

The public interface of this module is thread-safe.

class duplicity.tempdir.TemporaryDirectory(temproot=None)[source]

Bases: object

A temporary directory.

An instance of this class is backed by a directory in the file system created securely by the use of tempfile.mkdtemp(). Said instance can be used to obtain unique filenames inside of this directory for cases where mktemp()-like semantics is desired, or (recommended) an fd,filename pair for mkstemp()-like semantics.

See further below for the security implications of using it.

Each instance will keep a list of all files ever created by it, to faciliate deletion of such files and rmdir() of the directory itself. It does this in order to be able to clean out the directory without resorting to a recursive delete (ala rm -rf), which would be risky. Calling code can optionally (recommended) notify an instance of the fact that a tempfile was deleted, and thus need not be kept track of anymore.

This class serves two primary purposes:

Firstly, it provides a convenient single top-level directory in which all the clutter ends up, rather than cluttering up the root of the system temp directory itself with many files.

Secondly, it provides a way to get mktemp() style semantics for temporary file creation, with most of the risks gone. Specifically, since the directory itself is created securely, files in this directory can be (mostly) safely created non-atomically without the usual mktemp() security implications. However, in the presence of tmpwatch, tmpreaper, or similar mechanisms that will cause files in the system tempdir to expire, a security risk is still present because the removal of the TemporaryDirectory managed directory removes all protection it offers.

For this reason, use of mkstemp() is greatly preferred above use of mktemp().

In addition, since cleanup is in the form of deletion based on a list of filenames, completely independently of whether someone else already deleted the file, there exists a race here as well. The impact should however be limited to the removal of an ‘attackers’ file.

__init__(temproot=None)[source]

Create a new TemporaryDirectory backed by a unique and securely created file system directory.

tempbase - The temp root directory, or None to use system default (recommended).

cleanup()[source]

Cleanup any files created in the temporary directory (that have not been forgotten), and clean up the temporary directory itself.

On failure they are logged, but this method will not raise an exception.

dir()[source]

Returns the absolute pathname of the temp folder.

forget(fname)[source]

Forget about the given filename previously obtained through mktemp() or mkstemp(). This should be called after the file has been deleted, to stop a future cleanup() from trying to delete it.

Forgetting is only needed for scaling purposes; that is, to avoid n timefile creations from implying that n filenames are kept in memory. Typically this whould never matter in duplicity, but for niceness sake callers are recommended to use this method whenever possible.

mkstemp()[source]

Returns a filedescriptor and a filename, as per os.mkstemp(), but located in the temporary directory and subject to tracking and automatic cleanup.

mkstemp_file()[source]

Convenience wrapper around mkstemp(), with the file descriptor converted into a file object.

mktemp()[source]

Return a unique filename suitable for use for a temporary file. The file is not created.

Subsequent calls to this method are guaranteed to never return the same filename again. As a result, it is safe to use under concurrent conditions.

NOTE: mkstemp() is greatly preferred.

duplicity.tempdir.default()[source]

Obtain the global default instance of TemporaryDirectory, creating it first if necessary. Failures are propagated to caller. Most callers are expected to use this function rather than instantiating TemporaryDirectory directly, unless they explicitly desdire to have their “own” directory for some reason.

This function is thread-safe.