On Tuesday, August 28, 2018 2:10:22 AM CEST Richard Shea wrote:

I'm trying to use the -c option of twistd like this :

twistd web --wsgi bar.app -c foo.cer -k privkey.pem --https=4433

I'm pointing it at a cert with perms like this "-rw-r--r-- 1 root root" but twistd complains about a permission error .

I'm puzzled ... surely twistd only needs to read that file ?

Is it complaining about the permissions on the cert or on the private key? Some applications (like SSH) reject private keys if they are world-readable, as a precaution. Bye, Maarten

On Tue, Aug 28, 2018 at 5:54 AM Richard Shea wrote:

With Apache the process starts as root, reads the key and then makes the apache process run as a different, less powerful, user but I can't see how you can do the equivalent for twistd ? Am I overlooking something ?

twistd has `--uid` and `--gid` options for switching to another user after `privilegedStartService` runs. However, I'm not sure how much help this will be since there is a strong desire to replace twistd with twist and twist does not have these features. Perhaps someone who has been working on twist can explain the preferred workflow using that tool.

Thanks

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

On Aug 29, 2018, at 4:04 AM, Jean-Paul Calderone wrote:

On Tue, Aug 28, 2018 at 5:54 AM Richard Shea mailto:rshea@thecubagroup.com> wrote:

With Apache the process starts as root, reads the key and then makes the apache process run as a different, less powerful, user but I can't see how you can do the equivalent for twistd ? Am I overlooking something ?

twistd has `--uid` and `--gid` options for switching to another user after `privilegedStartService` runs. However, I'm not sure how much help this will be since there is a strong desire to replace twistd with twist and twist does not have these features. Perhaps someone who has been working on twist can explain the preferred workflow using that tool.

The origin of the desire to replace twistd with twist is that twistd represents an older, and worse, generation of UNIX administration practices. twistd assumes privilege separation is accomplished via daemons that start up (and, implicitly, import all their code) as root, and then carefully shed privileges on their own. this assumption was based in large part on the idea that twistd will want to bind privileged ports, and only root can bind privileged ports. twist assumes privilege separation is accomplished by starting your process in a container, or under a process supervision regime (such as systemd) which can hand it a privileged listening port. twistd assumes that process supervision is accomplished by an elaborate and frankly never quite fully specified dance involving PID files, self-truncation of logs, signal handling, and thus, writes pidfiles and daemonizes by default. twist assumes that process supervision is accomplished by using a process supervisor; either a container runtime, or systemd, or something like supervisord or ncolony. However, use of `twist` is gently encouraged, not mandated, as there are lots of old/bad systems where new versions of Twisted run, and will continue to run for some time. If your deployment constraints are better satisfied by twistd, by all means continue using it, report bugs in it, file PRs that fix those bugs. However, there are a long list of reasons why this new idiom is a lot better than the older one. One specific problem with read-certs-then-shed-privileges is that it means your process can never receive a new certificate without restarting; so no certificate rotation, no adding new subdomains on the fly. If your process has permissions to read and act on the certificate in memory, what benefit is there to making sure that it can't read it out of the filesystem a second time? If it's bound to a privileged port, a compromised node could provision its own certificate via Let's Encrypt anyway. So my suggestion would be to just provide the process long-lived read access to the certificates, via whatever access control mechanisms are available to you. If all you've got are filesystem permissions, u+rw g+r should do the trick, and then just put the user running `twistd` into the appropriate group. -g