precautionary - That would mean we assume that making the change won't break anything. We're setting this for new installs but forcing it on already deployed systems wouldn't be a good idea. We could add a NEWS entry to recommend making this change. It's definitely not a good idea to force it to happen.
On Tue, Mar 12, 2013 at 7:53 AM, Steven Chamberlain <ste...@pyro.eu.org>wrote: > Hi, > > On 12/03/13 03:33, Michael Lustfield wrote: > > In debian/nginx-common.postinst we have: > > > > configure) > > logdir="/var/log/nginx" > > # Ensure existance and right state of log files and directory > > if [ ! -d "$logdir" -a ! -L "$logdir" ]; then > > mkdir "$logdir" > > chown www-data:adm $logdir > > chmod 0750 $logdir > > fi > > > This should create the log directory if it doesn't already exist. We're > not > > enforcing this because the permissions could be changed. Is there any > better > > way to handle this than what we're doing now? I haven't tested, but it > seems > > that this should work. I'm sure I'm missing something... > > Else if it already exists as a directory, and are upgrading from package > version 1.2.1-2.2 or earlier, do a precautionary `chmod o-rx`? > > If ownership is still 'root:root', should chown to 'www-data:adm' so > that log parsers retain access. Maybe a NEWS entry could advise about > adding things into that group if they don't run as root or www-data but > still need to be able to read the nginx logs? > > > Some test cases I can think of are: > > * no log parsers in use - chmod o-rx is the important thing to do > > * logwatch - runs as root? changing the ownership/perms doesn't matter > > * awstats - the log parser part (update.sh) runs as user www-data > > * other CGI/PHP apps running as user www-data > > * other CGI/PHP apps running under separate uids - should be added to a > group that has read access. If the admin already changed the user or > group of /var/log/nginx, respect that, otherwise chgrp to adm and > suggest they add their log parsers into that group if necessary. The > alternative would be to just keep wide-open access... > > > Wide-open HTTP logs could be a breach of privacy, reveals usernames for > HTTP authentication, IP addresses of visitors, search queries or other > HTML form input with a GET action, locations of potentially sensitive > documents that would be otherwise impractical to guess, and provides a > catalogue of installed web apps that would likely assist an attacker if > this were some kind of shared host with other users. > > Thanks, > Regards, > -- > Steven Chamberlain > ste...@pyro.eu.org >
