Thank you very much for nginx.
When running nginx in a Solaris zone, I am unable to do a binary upgrade without
fully stopping and starting nginx. When I send the master process a USR2 signal,
it refuses to do the upgrade and writes the following log message:
2011/01/04 16:00:23 [crit] 3818#0: the changing binary signal is ignored: you should shutdown or terminate before either old or new binary's process
After looking at the code, it seems that nginx assumes if the master process's parent
does not have PID == 1, then nginx is not running in stand-alone daemon mode and the
upgrade should not be attempted.
My problem is that in Solaris zones the master process's parent is actually the
zsched process and this never has PID == 1. The real init process is not visible
inside the zone at all.
I am attaching a patch against 0.9.3 that (only if NGX_SOLARIS is defined) checks to
see if a root process can send a signal to init and, if not, assumes we are running
in a zone and goes ahead with the binary upgrade. With this patch I am able to do
0-downtime binary upgrades in Solaris zones with no problems. Any other solutions
would also be appreciated.
On 03.01.2011 17:48, Gena Makhomed wrote:
> On 03.01.2011 16:05, Piotr Karbowski wrote:
>>> master process running as root open/write files in /var/log/nginx
>>> - if nginx user have write permissions to this directory,
>>> 700 nginx:nginx - such setup is vulnerable by symlink attack
>>> better approach set permissions 750 root:nginx /var/log/nginx
>>> or 750 root:www-logs /var/log/nginx and add user nginx to group www-logs
>> Now when you mention it, if nginx worker have read perms there (as you
>> suggested above), then if user symlink to any log, he will be able fetch
>> it via nginx which is security hole.
> if nginx log files will have permissons nginx:root 244
> in this case nginx worker processes can only write(append)
> to log files, and can't read anything from it, even via symlink -
> it this case 403 Forbidden will be returned to access via symlink.
> but nginx source need to be patched for 244 logfile permissions,
> and this is can't be done via logrotate create 0244 nginx root
> directive, because nginx master process after USR1 signal
> explicitly reset logfiles permissioons to S_IRUSR|S_IWUSR
tested with 0.8.53, 0.8.54 and 0.9.3.
reset log files owner (nginx) permissions to S_IWUSR only.
first change log file permissions, thereafter change owner.
there is wrong event type used in if condition. This code-path is used only
when channel error occurs (so not every often, if at all), but it should be
Note: I don't have access to any Linux boxes, so this wasn't tested.
Piotr Sikora < piotr.sikora(a)frickle.com >