在上游读取时nginx权限被拒绝，即使以运行方式运行时也是如此

Question

我在nginx后面的uWSGI下有一个flask应用程序。在

*1 readv() failed (13: Permission denied) while reading upstream, client: 10.0.3.1, server: , request: "GET /some/path/constants.js HTTP/1.1", upstream: "uwsgi://unix:/var/uwsgi.sock:", host: "dev.myhost.com"

socket上的权限是可以的（666，并设置为与nginx相同的用户），事实上，即使我以root用户身份运行nginx，我仍然会遇到这个错误。在

flask app/uwsgi正在正确发送请求。但它只是没有被Nginx阅读。这是在ubuntutopic独角兽上。在

如果nginx进程拥有对套接字的完全访问权限，那么在哪里权限可能会被拒绝？在

作为一个复杂的因素，这个服务器运行在一个装有ubuntu14.04的容器中。而这个装置以前是有用的。。。但我最近把主机升级到了14.10。。。我完全理解这可能是问题的原因。但在降级主机或升级容器之前，我想了解原因。在

当我在生成此错误的worker上运行strace时，我看到它发出的调用如下所示：

^{pr2}$

14似乎是这个系统调用创建的文件描述符

socket(PF_LOCAL, SOCK_STREAM, 0)        = 14

所以它不能从刚刚创建的本地套接字读取数据？在

Answer 1

这个问题可能是在内核3.16中引入的，因为它不会在14.04和3.13内核中重现。奇怪的幻影虫确实要为此负责。在

不幸的是@aychedee的解决方案对我无效。在我的例子中，我必须在docker run命令中添加以下参数以解决此问题：

docker run  security-opt apparmor:unconfined ...

如果有人知道问题的当前状态，请考虑在以下答案下添加评论：）

Answer 2

好吧！所以问题是，我认为，与this bug有关。似乎即使apparmor没有被配置为阻止访问容器内的套接字，它实际上是在做一些事情来阻止从它们读取（尽管不是创建…），所以关闭容器的apparmor（following these instructions）来修复它。在

两条相关的线路是：

sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start

sudo ln-s/etc/设备/usr.bin.lxc型-启动/etc/apparmor.d/disabled/

加上

^{pr2}$

到容器配置文件。在

注：这些错误没有记录在任何设备日志中。在