Opened 9 years ago
Closed 9 years ago
#836 closed defect (worksforme)
the file existence check fails if permission is denied
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | documentation | Version: | 1.9.x |
Keywords: | Cc: | ||
uname -a: | Linux ip-192-168-1-166 3.10.0-229.14.1.el7.x86_64 #1 SMP Tue Sep 15 15:05:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux | ||
nginx -V: |
nginx version: nginx/1.6.3
built by gcc 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_spdy_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-mail --with-mail_ssl_module --with-pcre --with-pcre-jit --with-google_perftools_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E' |
Description
I'm using the following block to check for the file existence:
if (-e some/path/file) { return 404; }
The trick here is that the "some/path" directory has permissions 0711 and the "some/path/file" file is not readable to nginx. The expectation is that nginx could confirm the existence of the file despite that the process cannot read/access the file. The reality is that nginx fails the check.
Just to illustrate: I switched to the nginx user and did a stat on the file:
-bash-4.2$ id uid=998(nginx) gid=996(nginx) groups=996(nginx) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -bash-4.2$ ls -ld /home/w_wp/public_html drwx--x--x. 5 w_wp p_wp 4096 Nov 19 00:21 /home/w_wp/public_html -bash-4.2$ stat /home/w_wp/public_html/index.php File: '/home/w_wp/public_html/index.php' Size: 418 Blocks: 8 IO Block: 4096 regular file Device: ca01h/51713d Inode: 142130 Links: 1 Access: (0640/-rw-r-----) Uid: ( 1001/ w_wp) Gid: ( 1001/ p_wp) Context: unconfined_u:object_r:httpd_user_content_t:s0 Access: 2015-11-19 01:59:00.742000000 +0000 Modify: 2015-09-03 03:33:24.000000000 +0000 Change: 2015-11-19 01:58:57.836000000 +0000 Birth: - -bash-4.2$ ps uw -C nginx USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 10981 0.0 0.2 109584 2096 ? Ss 02:15 0:00 nginx: master process /usr/sbin/nginx nginx 10982 0.0 0.3 110104 3412 ? S 02:15 0:00 nginx: worker process -bash-4.2$
Note:
See TracTickets
for help on using tickets.
Works fine for me here. Note though:
-e
is a file path, not URI, and it's incorrect to assume it's resolved from document root. To make things clear, use absolute path or $document_root explicitly, e.g.:disable_symlinks
is used on some systems, see docs.semanage permissive -a httpd_t
should do the trick).