Nginx does not re-open log files on SIGUSR1.

[Gena Makhomed]

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

patches:
tested with 0.8.53, 0.8.54 and 0.9.3.

nginx-logfiles-permissions-1.patch:
reset log files owner (nginx) permissions to S_IWUSR only.

nginx-logfiles-permissions-2.patch:
first change log file permissions, thereafter change owner.

-- 
Best regards,
  Gena
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: nginx-logfiles-permissions-1.patch
URL: <http://nginx.org/pipermail/nginx-devel/attachments/20110103/63f88d3d/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: nginx-logfiles-permissions-2.patch
URL: <http://nginx.org/pipermail/nginx-devel/attachments/20110103/63f88d3d/attachment-0001.ksh>