Set tight permissions for key files

[zenhack]

Issue by Lekensteyn
Saturday Dec 05, 2015 at 15:11 GMT
Originally opened as kuba/simp_le#34

---

Ensure that key files are not world-readable.

temp_umask is based on test.support.temp_umask.

Fixes #29

---

If older Python versions do not have to be supported, then the test code could become something like:

@temp_umask(0o022)
def test_it():
    ...

---

Lekensteyn included the following code: https://github.com/kuba/simp_le/pull/34/commits

[zenhack]

Comment by danmilon
Tuesday Dec 08, 2015 at 10:01 GMT

---

World readable private key? ouch!
LGTM.

[zenhack]

Comment by Lekensteyn
Tuesday Dec 08, 2015 at 16:14 GMT

---

Updated patchset against latest master, added a rough separate test case as AccountKey got removed.

[zenhack]

Comment by kuba
Tuesday Dec 08, 2015 at 20:43 GMT

---

There are 3 parties potentially involved with the typical usage scenario:

1. user under which the client is run
2. user that runs httpd
3. root

If we assume that those three parties are different users (say nobody, nginx, root), then there are some usability problems, because:

• (1) needs to open and write: account key, chain, cert and key
• (2) needs to read chain, cert and key
• we don't run as root, so we cannot chmod or chown

Restricting key file to 0o600 would mean that httpd is not able to read necessary files :(

I would like those kind of cases to be clearly sorted out (and by that I mean short design doc, possibly included in the repo itself) before merging.

[zenhack]

Comment by danmilon
Tuesday Dec 08, 2015 at 21:31 GMT

---

AFAIK apache runs as root to bind to privilaged ports and/or read the private key, and then spawns other processes as a non-privilaged user (e.g. www-data) to do the actual request handling.

I don't know if other web servers work similarly.

[zenhack]

This PR doesn't look like quite the right solution, so I'm going to close. For reference, this was intended to solve kuba/simp_le#29 which corresponds to #6.