file and directory permissions on the data directory about devpi

[devpi-bot]

Original comment by @hpk42

I think i agree. Note quite sure at the moment, why 0600 is used, btw.

[devpi-bot]

Original comment by @AvdN

My first guess would be that this is the default for starting a service (probably along with double forking and chdir("/"). If you want I can investigate where that comes from.

[devpi-bot]

Original comment by @hpk42

Ah ok, that devpi-server creating 0600 files is running under supervisor control? That might explain it. Haven't looked into according defaults.

[devpi-bot]

Original comment by @AvdN

The automatic server has the same behaviour, so it is not supervisor specific, but probably the way the server starts and spawns itself.

[devpi-bot]

Original comment by @hpk42

be more careful about os.umask call, addresses issue6

→ <<cset 4e1d6efcb893>>

[devpi-bot]

Original comment by @AvdN

This is probably caused by the use of tempfile.NamedTemporaryFile ( it calls tempfile._mkstemp_inner() which hardcodes the file permission to 0600 ).
In keyfs.py TypedKey.move() just os.renames that file, without looking at the file permissions.
I still think all keyfs generated data should be 644 except for the toplevel directory.

[devpi-bot]

Original comment by @hpk42

Thanks for finding this out. I think we should use the current umask of the process instead of 0600. Could you provide a PR for that?

The default of NamedTemporaryFile of 0600 is probably because usually such files are created in global temp directories and thus the mask prohibits other users from messing around. We are using our own controled subdir so that logic doesn't apply.

[devpi-bot]

Original comment by @AvdN

Fixed in https://bitbucket.org/hpk42/devpi/commits/4ac05c2f2c1023b89a1eabe8c602117d4c52a344