Opened 8 years ago
Closed 8 years ago
#1065 closed defect (invalid)
include directive with mask does not match symlinks
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | 1.11.x |
| Keywords: | include glob symlink link | Cc: | |
| uname -a: | Linux $myhostname 4.1.31-1-MANJARO #1 SMP PREEMPT Wed Aug 24 00:14:37 UTC 2016 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.11.3
built with OpenSSL 1.0.2h 3 May 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/bin/nginx --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --user=http --group=http --http-log-path=/var/log/nginx/access.log --error-log-path=stderr --http-client-body-temp-path=/var/lib/nginx/client-body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-ipv6 --with-pcre-jit --with-file-aio --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-threads |
||
Description
When including other conf files with a glob mask like include /etc/nginx/path/*.conf; then nginx does not seem to match symlinks.
The problem can be reproduced like this (also attached):
mkdir -p nginxincludetest
cd nginxincludetest
mkdir -p normal target linked
cat > normal/normal.conf <<CONFIG
# NORMAL
server {
listen 127.0.0.1:8123;
}
CONFIG
cat > target/linked.conf <<CONFIG
# LINKED
server {
listen 127.0.0.1:8124;
}
CONFIG
ln -sf {target,linked}/linked.conf
cat > nginx.conf <<CONFIG
pid nginx.pid;
events {
worker_connections 1;
}
http {
include normal/*.conf;
include linked/*.conf;
}
CONFIG
nginx -T -c $PWD/nginx.conf
Expected:
nginx: the configuration file $HOME/nginxincludetest/nginx.conf syntax is ok
nginx: configuration file $HOME/nginxincludetest/nginx.conf test is successful
# configuration file $HOME/nginxincludetest/nginx.conf:
pid nginx.pid;
events {
worker_connections 1;
}
http {
include normal/*.conf;
include linked/*.conf;
}
# configuration file $HOME/nginxincludetest/normal/normal.conf:
# NORMAL
server {
listen 127.0.0.1:8123;
}
# configuration file $HOME/nginxincludetest/linked/linked.conf:
# LINKED
server {
listen 127.0.0.1:8124;
}
Result:
nginx: the configuration file $HOME/nginxincludetest/nginx.conf syntax is ok
nginx: configuration file $HOME/nginxincludetest/nginx.conf test is successful
# configuration file $HOME/nginxincludetest/nginx.conf:
pid nginx.pid;
events {
worker_connections 1;
}
http {
include normal/*.conf;
include linked/*.conf;
}
# configuration file $HOME/nginxincludetest/normal/normal.conf:
# NORMAL
server {
listen 127.0.0.1:8123;
}
(Also tested with version 1.10.1)
Attachments (1)
Change History (2)
by , 8 years ago
| Attachment: | nginxincludetest.sh added |
|---|
comment:1 by , 8 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
The symlink created by
ln -sf {target,linked}/linked.conf
won't point from linked/linked.conf to target/linked.conf you've created. Rather, it will point to linked/targed/linked.conf, as the symlink is relative and is in the linked/ directory.
That is, the configuration you test is broken. In no case it would produce the "expected" result above.
On FreeBSD this results in the following error:
nginx: [emerg] open() "/path/to/nginxincludetest/linked/linked.conf" failed (2: No such file or directory) in /path/to/ticket1065/nginxincludetest/nginx.conf:7
This makes the error obvious.
On Linux with glibc, such broken symlinks are just skipped by glob(), so nginx doesn't see them at all and doesn't try to load. No idea why glibc does this - this looks wrong to me as it hides the error and makes debugging harder, but may be there are reasons. Relevant glibc bug was open in 2005 and is still open (there was an attempt to close it - without any explanation though), see https://sourceware.org/bugzilla/show_bug.cgi?id=866.
Script to reproduce