如何将systemd作为非特权用户部署Twistd https应用程序（.tac）？

Posted 2021-03-27

我的https（端口443）扭曲的应用程序（.tac）可以很好地部署为systemd服务，但是单元文件需要用户：root来监听/绑定1000以下的端口。问题是twistd也以用户：root运行。

如何监听/绑定端口443然后切换为非特权用户扭曲.tac？

我想遵循“权限分离”的最佳实践，并避免像setcap'cap_net_bind_service = + ep'或端口转发这样的解决方法，详见here。

我尝试使用Socket Activation和.service单元文件进行systemd。我的.socket工作在特权端口443上侦听/绑定。而.service文件以非特权用户的身份启动扭曲的.tac应用程序，但套接字切换不起作用，并且以“权限被拒绝”错误退出。搜索后，我发现“已知问题：Twisted不支持在继承自systemd的套接字上侦听SSL连接”这个Twisted doc的最后一行。我使用Twisted 18.9.0 ubuntu 18.04。

使用以下.service和.socket文件取得部分成功：

我的Systemd服务单元文件：

[Unit]
Description=twistd https application
#Requires=testtls.socket

[Service]
ExecStart=/usr/bin/twistd --nodaemon --pidfile= --python=/ws/twistdhttps.tac
WorkingDirectory=/srv/web/https
#User=nobody   #twistd .tac permission denied
#Group=nogroup #twistd .tac permission denied
User=root   #twistd .tac works but no separation of privileges
Group=root  #twistd .tac works but no separation of privileges

Restart=always
#NonBlocking=true

[Install]
WantedBy=multi-user.target

系统套接字文件testtls.socket：

[Socket]
ListenStream=0.0.0.0:443

[Install]
WantedBy=sockets.target

答案

我制定了一个带有两个systemd文件的反向代理类型解决方案，与从一个systemd文件中交换套接字相比，我意识到这是一种优雅的方式。我的一个.service文件有一个root用户，另一个是非特权用户。重定向.service文件使用twisted.web.util.redirect（最新文档可以找到here）将443重定向到8443.另一个.service文件侦听端口8443，最重要的是作为非特权用户。

测试和工作正常，然而，一些有同样问题的人可能想知道这与端口转发有什么不同，因为与.socket tls切换相比，反向代理只是另一种类型的解决方法。

使用iptables的端口转发可以工作，并且由内核处理它似乎可能比运行反向代理服务器的额外负载更快。对于我的用例，我决定使用反向代理，因为它增加了额外的安全层，并且更容易在代理上保持链接完整，如here所述。

暂时我接受这是最好的答案，因为它会帮助遇到同样问题的其他人，但我希望有人发布更好，更优雅的解决方案。