Command nginx -t create file modsec-shared-collections in directory where it run

[unix196]

Nginx build with connector modsecurity-nginx. Modsecurity build with lmdb support (--with-lmdb)

server /etc/nginx # ls -al
...
-rw-r--r--   1 root root  3957 Aug 10  2017 mime.types
drwxr-xr-x   2 root root  4096 Feb 19 12:38 modsec
-rw-r--r--   1 root root  5494 Jan 23 20:55 nginx.conf
drwxr-xr-x   2 root root  4096 Jul  9 12:54 sites-available
drwxr-xr-x   2 root root  4096 Jul  9 12:55 sites-enabled

server /etc/nginx # nginx -t
nginx: [emerg] too long parameter "..." started in /etc/nginx/sites-enabled/modsec-shared-collections:1
nginx: configuration file /etc/nginx/nginx.conf test failed
server  /etc/nginx # ls -al
...
-rw-r--r--   1 root root    3957 Aug 10  2017 mime.types
drwxr-xr-x   2 root root    4096 Feb 19 12:38 modsec
-rw-r--r--   1 root root 1048576 Jul  9 12:56 modsec-shared-collections
-rw-r--r--   1 root root    8192 Jul  9 12:56 modsec-shared-collections-lock

server ~/test# ls -l
total 0
server ~/test # nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
server ~/test # ls -l
total 12
-rw-r--r-- 1 root root 1048576 Jul  9 13:23 modsec-shared-collections
-rw-r--r-- 1 root root    8192 Jul  9 13:23 modsec-shared-collections-lock

This is very strange behavior. If I change directory to /etc/nginx, then run nginx -t - after that my nginx config is broken.

ldd /usr/local/modsecurity/lib/libmodsecurity.so
	linux-vdso.so.1 (0x00007ffc5f95e000)
	libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f339cc37000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f339ca2f000)
	libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f339c674000)
	liblmdb.so.0 => /usr/lib/x86_64-linux-gnu/liblmdb.so.0 (0x00007f339c45f000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f339c1ed000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f339be6b000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f339bb67000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f339b7c8000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f339d2de000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f339b5b1000)
	libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f339b38b000)
	libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f339b169000)
	librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f339af4c000)
	libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 (0x00007f339ad1f000)
	libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f339ab11000)
	libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x00007f339a8a8000)
	libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (0x00007f339a442000)
	libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f339a1f7000)
	libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f3399f1d000)
	libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f3399cea000)
	libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f3399ae6000)
	liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f33998d7000)
	libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f3399686000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f339946c000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f339924f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f339904b000)
	libicui18n.so.57 => /usr/lib/x86_64-linux-gnu/libicui18n.so.57 (0x00007f3398bd1000)
	libicuuc.so.57 => /usr/lib/x86_64-linux-gnu/libicuuc.so.57 (0x00007f3398829000)
	libicudata.so.57 => /usr/lib/x86_64-linux-gnu/libicudata.so.57 (0x00007f3396dac000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3396b86000)
	libunistring.so.0 => /usr/lib/x86_64-linux-gnu/libunistring.so.0 (0x00007f339686f000)
	libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f33964d6000)
	libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f33962a1000)
	libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f339606a000)
	libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f3395de7000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f3395ad7000)
	libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f33958cb000)
	libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f33956c7000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f33954b0000)
	libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f3395295000)
	libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f3395030000)
	libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007f3394dfc000)
	libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f3394be9000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f33949d5000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f33947cc000)

[zimmerle]

Indeed this is annoying.

Ideally the lmdb file should be created in a path relative to execution binary, in that case: nginx. Not sure if we need a configuration flag for that, where the user will be able to pin point the location of the collection. That seem to be a good idea as we want to support others such us: Redis (#1139) and Memcache (#1140). Both Memcache and Redis, demands specific parameters at runtime (e.g. Server address).

[martinhsv]

The location of the directory holding the lmdb data can currently be specified by using the nginx configuration item working_directory.

Implementing additional functionality under this issue would mostly be advantageous if users find this existing method insufficiently flexible.

If we do implement something here, it would likely be to activate the SecDataDir ModSecurity item for that purpose.