> On Aug 29, 2018, at 4:04 AM, Jean-Paul Calderone <exar...@twistedmatrix.com> > wrote: > > On Tue, Aug 28, 2018 at 5:54 AM Richard Shea <rs...@thecubagroup.com > <mailto:rs...@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
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
