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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
