[PATCH] The directives such as user, rlimit_core should also be effective on master process
# HG changeset patch
# User Kunal Pariani kpari...@zimbra.com
# Date 1407194790 25200
# Mon Aug 04 16:26:30 2014 -0700
# Node ID f25ab24517bb5e45b1b7fa1a1502b907f2cff213
# Parent f8764e20fcd7f87d98fe97f82b2a8d0a77ed9097
The directives such as user, rlimit_core should also be effective on master
process
diff -r f8764e20fcd7 -r f25ab24517bb src/os/unix/ngx_process_cycle.c
--- a/src/os/unix/ngx_process_cycle.c Fri Aug 01 20:39:22 2014 -0700
+++ b/src/os/unix/ngx_process_cycle.c Mon Aug 04 16:26:30 2014 -0700
@@ -93,6 +93,7 @@
ngx_msec_t delay;
ngx_listening_t *ls;
ngx_core_conf_t *ccf;
+struct rlimit rlmt;
sigemptyset(set);
sigaddset(set, SIGCHLD);
@@ -139,6 +140,64 @@
ngx_start_worker_processes(cycle, ccf-worker_processes,
NGX_PROCESS_RESPAWN);
+
+if (ccf-rlimit_nofile != NGX_CONF_UNSET) {
+ rlmt.rlim_cur = (rlim_t) ccf-rlimit_nofile;
+ rlmt.rlim_max = (rlim_t) ccf-rlimit_nofile;
+
+ if (setrlimit(RLIMIT_NOFILE, rlmt) == -1) {
+ ngx_log_error(NGX_LOG_ALERT, cycle-log, ngx_errno,
+ setrlimit(RLIMIT_NOFILE, %i) failed,
+ ccf-rlimit_nofile);
+}
+}
+
+if (ccf-rlimit_core != NGX_CONF_UNSET) {
+ rlmt.rlim_cur = (rlim_t) ccf-rlimit_core;
+ rlmt.rlim_max = (rlim_t) ccf-rlimit_core;
+
+ if (setrlimit(RLIMIT_CORE, rlmt) == -1) {
+ ngx_log_error(NGX_LOG_ALERT, cycle-log, ngx_errno,
+ setrlimit(RLIMIT_CORE, %O) failed,
+ ccf-rlimit_core);
+}
+}
+
+#ifdef RLIMIT_SIGPENDING
+if (ccf-rlimit_sigpending != NGX_CONF_UNSET) {
+ rlmt.rlim_cur = (rlim_t) ccf-rlimit_sigpending;
+ rlmt.rlim_max = (rlim_t) ccf-rlimit_sigpending;
+
+ if (setrlimit(RLIMIT_SIGPENDING, rlmt) == -1) {
+ ngx_log_error(NGX_LOG_ALERT, cycle-log, ngx_errno,
+ setrlimit(RLIMIT_SIGPENDING, %i) failed,
+ ccf-rlimit_sigpending);
+}
+}
+#endif
+
+if (geteuid() == 0) {
+ if (setgid(ccf-group) == -1) {
+ ngx_log_error(NGX_LOG_EMERG, cycle-log, ngx_errno,
+ setgid(%d) failed, ccf-group);
+/* fatal */
+ exit(2);
+}
+
+if (initgroups(ccf-username, ccf-group) == -1) {
+ ngx_log_error(NGX_LOG_EMERG, cycle-log, ngx_errno,
+ initgroups(%s, %d) failed,
+ ccf-username, ccf-group);
+}
+
+if (setuid(ccf-user) == -1) {
+ ngx_log_error(NGX_LOG_EMERG, cycle-log, ngx_errno,
+ setuid(%d) failed, ccf-user);
+/* fatal */
+ exit(2);
+}
+}
+
ngx_start_cache_manager_processes(cycle, 0);
ngx_new_binary = 0;
Thanks
-Kunal___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] The directives such as user, rlimit_core should also be effective on master process
Hello! On Tue, Aug 05, 2014 at 02:26:59AM -0500, Kunal Pariani wrote: # HG changeset patch # User Kunal Pariani kpari...@zimbra.com # Date 1407194790 25200 # Mon Aug 04 16:26:30 2014 -0700 # Node ID f25ab24517bb5e45b1b7fa1a1502b907f2cff213 # Parent f8764e20fcd7f87d98fe97f82b2a8d0a77ed9097 The directives such as user, rlimit_core should also be effective on master process No, thanks. The master process should remain root to be able to read priveleged configuration files during configuration reload, open listening sockets on priveleged ports and so on. -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] The directives such as user, rlimit_core should also be effective on master process
--On Tuesday, August 05, 2014 12:58 PM +0400 Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Tue, Aug 05, 2014 at 02:26:59AM -0500, Kunal Pariani wrote: # HG changeset patch # User Kunal Pariani kpari...@zimbra.com # Date 1407194790 25200 # Mon Aug 04 16:26:30 2014 -0700 # Node ID f25ab24517bb5e45b1b7fa1a1502b907f2cff213 # Parent f8764e20fcd7f87d98fe97f82b2a8d0a77ed9097 The directives such as user, rlimit_core should also be effective on master process No, thanks. The master process should remain root to be able to read priveleged configuration files during configuration reload, open listening sockets on priveleged ports and so on. The drop to the user happens *after* the files ports have been opened already. This is how many *nix server processes work, as an additional security measure. We've been using nginx with this patch since nginx 0.5.37, so it's quite heavily tested. See also: http://www.dwheeler.com/secure-class/Secure-Programs-HOWTO/minimize-privileges.html and http://www.ibm.com/developerworks/linux/library/l-sppriv/index.html -Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] The directives such as user, rlimit_core should also be effective on master process
On 05 Aug 2014, at 21:10, Quanah Gibson-Mount qua...@zimbra.com wrote: --On Tuesday, August 05, 2014 12:58 PM +0400 Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Tue, Aug 05, 2014 at 02:26:59AM -0500, Kunal Pariani wrote: # HG changeset patch # User Kunal Pariani kpari...@zimbra.com # Date 1407194790 25200 # Mon Aug 04 16:26:30 2014 -0700 # Node ID f25ab24517bb5e45b1b7fa1a1502b907f2cff213 # Parent f8764e20fcd7f87d98fe97f82b2a8d0a77ed9097 The directives such as user, rlimit_core should also be effective on master process No, thanks. The master process should remain root to be able to read priveleged configuration files during configuration reload, open listening sockets on priveleged ports and so on. The drop to the user happens *after* the files ports have been opened already. This is how many *nix server processes work, as an additional security measure. We've been using nginx with this patch since nginx 0.5.37, so it's quite heavily tested. See also: http://www.dwheeler.com/secure-class/Secure-Programs-HOWTO/minimize-privileges.html and http://www.ibm.com/developerworks/linux/library/l-sppriv/index.html nginx master process does not process incoming connections. It just keep listen ports open. If master process will drop root privileges it will be unable to open new listen ports, files, etc. after graceful reconfiguration on the HUP signal. -- Igor Sysoev http://nginx.com ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
