Nginx permission denied while reading upstream - even when running as root

Question

I have a flash application running under uWSGI for nginx.

*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" 

The socket permissions are fine (666 and set for the same user as nginx), in fact, even when I run nginx as root, I still get this error.

The flash / uwsgi application sends the request properly. But it just cannot be read by Nginx. This is on Ubuntu Utopic Unicorn.

Any idea when permission might be denied if the nginx process has full socket access?

As a complicating factor, this server runs in a container with Ubuntu 14.04 installed. And this setting was used to work ... but I recently updated the host to 14.10 ... I can fully understand that this could be the cause of the problem. But before I drop the host or upgrade the container, I want to understand why.

When I run strace for the worker that generates this error, I see that the call it makes looks something like this:

 readv(14, 0x7fffb3d16a80, 1) = -1 EACCES (Permission denied) 

14 is represented by the file descriptor created by this system call

 socket(PF_LOCAL, SOCK_STREAM, 0) = 14 

So what can he not read from the local socket that has just been created?

Answer 1

Good! Therefore, the problem was, I think, related to this error . It seems that even if apparmor was not configured to prevent access to sockets inside containers, it actually did something to prevent reading from them (although not creating ...), so disable apparmor for the container ( according to these instructions ) worked to fix this.

Two matching lines:

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

sudo ln -s / etc / apparmor.d / usr.bin.lxc-start / etc / apparmor.d / disabled /

and adding

 lxc.aa_profile = unconfined 

In the container configuration file.

Note. These errors were not recorded in any arrangement logs.

Answer 2

This problem probably appeared in kernel 3.16 because it does not reproduce 14.04 with kernel 3.13. The answer to this question was really strange.

Unfortunately, @aychedee's solution does not work for me. In my case, I had to add the following parameter to the docker run to get rid of the problem:

 docker run --security-opt apparmor:unconfined ... 

If someone knows what the current state of the problem is, consider adding a comment to this answer :)