[Systems] Fwd: [Systems-logs] Cron <www-data at sunjammer> [ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh

[Samuel Cantero]

I found this on /usr/share/doc/awstats/README.debian.gz:

As AWStats is used both as a CGI-script and offline, it is by default run
as uid=www-data in cron jobs so that generated files are accessible from
CGI as well.  *By default Apache stores (since version*
*1.3.22-1) logfiles with uid=root and gid=adm*, so you need to either...

1) Change the rights of the logfiles so that www-data has at least read
access.  For example:
    * change line in /etc/logrotate.d/apache2 to: "create 644 root adm"
    * change permissions of existing files: chmod 644 /var/log/apache2/*.log

2) As 1) but change to a specific user, and use the suEXEC feature of
Apache to run as same user (and either change the right of /var/lib/awstats
as well or use another directory).  This is more complicated, but then the
logs are not generally accessible to the server (which was probably the
point of the Apache default).

The easiest one to apply is the first solution but the downside here is
that apache log files will be world-readable. The second one is more
complicated and I don't want to play with it. An improperly configured
suExec feature can cause a lot of problems and security holes.

So, in order to avoid executing the cron job as root user and do not allow
www-data to read the apache log files I applied the solution recommended in
launchpad. I created a system user called awstats without home and shell
and added it to www-data and adm group. The first one in order to write to
awstats file and the second one in order to read the apache log files.

Trying to guest how apache writes to logs, I would say that the first
apache process owned by root is in charge. This process is the parent one
for all the forked processes. (0=root, 33=www-data).

scg at sunjammer:~$ ps lax | grep apache2
5     *0* *15179*     1  20   0 618016 27472 poll_s Ss   ?          4:35
/usr/sbin/apache2 -k start
5    33 15460 *15179*  20   0 314260 10972 poll_s S    ?          0:00
/usr/sbin/apache2 -k start
5    33 21996 *15179*  20   0 703208 57584 lock_f S    ?          0:03
/usr/sbin/apache2 -k start
5    33 22044 *15179*  20   0 693452 47408 lock_f S    ?          0:02
/usr/sbin/apache2 -k start
.....

Best regards,

Samuel C.

On Wed, Feb 24, 2016 at 11:23 PM, Bernie Innocenti <bernie at codewiz.org>
wrote:

> On 02/24/2016 11:20 AM, Samuel Cantero wrote:
> > Hi all,
> >
> > I have received a bunch of this email. The user www-data is executing
> > the awstats update script and it doesn't have permission to read the
> > /var/log/apache2/codewiz.org/codewiz.org-access.log
> > <http://codewiz.org/codewiz.org-access.log> apache log file. The same
> > for /var/log/apache2/access.log. The permission is set to:
> >
> > -rw-r----- 1 root adm       9,2M Feb 24 14:05 codewiz.org-access.log
> > -rw-r----- 1 root adm 9,8M Feb 24 14:13 access.log
> >
> > However, all the old log files have the following permission:
> >
> > -rw-rw---- 1 root www-data  429K Jan  4  2015
> > codewiz.org-access.log-20150104.xz
> >
> > I guess logrotate (/etc/logrotate.d/apache2) is in charge of setting
> > this permission. So I checked it and I found the following directive:
> > create 640 root adm. I can find the same pattern in the other log files.
> > I guess we should change it to: create 660 root www-data.
> >
> > If you are ok with me, I will proceed to change it and fix manually the
> > permissions for the current log files.
>
> I was also surprised to see the change from www-data to adm. How does
> Apache even write into files owned by root:adm if it's in the www-data
> group?
>
> I guess something changed in how Ubuntu or Debian handles apache logs.
> These bugs seem relevant:
>
>  https://bugs.launchpad.net/ubuntu/+source/awstats/+bug/1252467
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745620
>
> Not sure what the best fix is, feel free to experiment.
>
> --
>  _ // Bernie Innocenti
>  \X/  http://codewiz.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/systems/attachments/20160227/b2b96fd1/attachment.html>