Annif does not adhere umask setting for data files

[juhoinkinen]

Annif uses tempfile.mkstemp() for saving some vocabulary and project data files in the atomic_save() method. The file permissions of the files created are always only read and write for the owner; the permissions cannot be set by umask (Python docs).

For example:

umask 0007  # normally results to permission -rw-rw----

annif load-vocab arch tests/corpora/archaeology/yso-archaeology.ttl
ls -l data/vocabs/arch/
total 76
-rw------- 1 <myuser> <mygroup> 10597 Jan 27 13:10 subjects.csv
-rw------- 1 <myuser> <mygroup> 29177 Jan 27 13:10 subjects.dump.gz
-rw-rw---- 1 <myuser> <mygroup> 32252 Jan 27 13:10 subjects.ttl

As seen above, only subjects.ttl gets the desired permissions (because that file is just copied to the vocabulary directory).

This is a problem for multiuser environments. The same problem might exist also in some of the libraries Annif uses and which save data files (but not with Omikuji, for which permission problems were noted). The backends that create the vectorizer file are affected via Annif's atomic_save().

At least these approaches have been used for resolving this issue:

• Get the umask value and then chmod the files with the value, like in this SO answer.
• Do not use tempfile, but create the data files directly in the destination directory, but with filenames with UUIDs, like in this PR.

[osma]

The idea of atomic_save, as the name implies, is to perform the save atomically: either it succeeds, or if there is a problem in the middle of the operation (for example out of disk space, or the process gets killed for any reason), nothing will be written to the final destination path. It's the os.rename at the end that ensures(?) atomicity:

Annif/annif/util.py

Line 50 in 736353f

os.rename(fn, newname)

I think it would make sense to chmod the file to the expected umask value just before calling os.rename.