#2550 closed defect (duplicate)
Using the 'sudo ./nginx -t' command results in the issue of the ownership of the 'proxy_temp' and other temporary folders being changed.
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | documentation | Version: | 1.20.x |
| Keywords: | configuration check | Cc: | 333eelrm@… |
| uname -a: | Linux localhost.localdomain 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.20.2
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) built with OpenSSL 1.0.2i 22 Sep 2016 TLS SNI support enabled configure arguments: --prefix=/vdata/k8s/deployer/app/openresty/nginx --with-pcre=../pcre-8.40 --with-zlib=../zlib-1.2.11 --with-openssl=../openssl-OpenSSL_1_0_2i --with-http_stub_status_module --with-http_ssl_module --with-stream --add-module=../nginx-module-vts-0.1.18 --add-module=../nginx-module-stream-sts-0.1.1 --add-module=../nginx-module-sts-0.1.1 |
||
Description
Hello, I am a DevOps professional from a Chinese company responsible for Nginx product operations. You can call me Peng Li. We encountered the following issue when using Nginx open-source version 1.20.2 in our production environment. On October 12th, we made modifications to the nginx_8000.conf configuration file and executed the 'sudo nginx -t' command. Following this, we noticed that the owner of all temporary files in the nginx directory had been changed to "nobody." Upon consulting the documentation, we discovered that this occurred due to the 'user' directive in the configuration file not being set to the current user.
In light of the above issue, we examined the source code of the '-t' command and have some reservations about its functionality. As a tool for checking and validating Nginx configurations, wouldn't it be more reasonable for 'nginx -t' to produce an error when the user specified in the configuration file via the 'user' directive doesn't match the current owner of the temp files, rather than directly altering the user of the temp folder to "nobody"? We sincerely hope that the official developers can provide us with a detailed explanation. We deeply appreciate your assistance!
Change History (2)
comment:1 by , 7 months ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
comment:2 by , 8 days ago
During routine checks of Nginx configuration using the 'sudo ./nginx -t' command, it has been observed that the ownership of temporary folders such as 'proxy_temp' changes to "nobody". This behavior, although consistent with Nginx’s handling of directory ownership during startup, raises concerns about the appropriateness of this action during configuration testing. Should the 'nginx -t' command alter the ownership of temporary files and directories, potentially affecting subsequent server operations? How can this issue be addressed to prevent unintended side effects while still ensuring configuration validity?
After modifying the Nginx configuration file and running 'sudo ./nginx -t', the ownership of all temporary files in the Nginx directory changes, leading to operational inconsistencies. The current behavior, as per Nginx documentation and source code review, indicates that this ownership change is by design, meant to mimic actual startup conditions to ensure that the server would start successfully with the new configuration. However, this automatic change can disrupt the environment, especially in a development or staging setting where multiple configurations are tested frequently.
What are the best practices for managing file ownership and permissions in a shared Nginx environment to prevent such issues?
The
nginx -tcommand does various configuration testing, including creating logs and directories, and fixing ownership of appropriate directories - much like during normal nginx startup. Since nginx does fix ownership of directories during startup - this is somethingnginx -tis expected to do as well, to ensure that nginx startup will actually succeed with the configuration being tested.Duplicate of #1791.