[Pkg-awstats-devel] RFC - cron-related stuff

[Sergey B Kirpichev]

On Fri, Apr 2, 2010 at 3:53 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> First the syntax of my compact listings:
>
> some entity: executes[as user] < input[:ingroup] > output[user:group]
>
> Now your one single proposal - split into different use cases:
>
> Your proposal - without user interaction:
>
> cron:   logrotate[root] < httpd > logs[root:adm]
> cron:   awstats[awstats] < logs[:adm] > stats[awstats:awstats]
>
> Result: Noone can access the stats (as noone by default is member of the
> awstats group).
>
> Problem: requires adding awstats to adm group which in itself is ok, but
> sharing awstats data in a wider context potentially leaks other
> adm-accessible data.
>
> Question: Do you perhaps mean that stats by default should be stored
> readable by the adm group?

We can use strict permissions on home directory of the awstats user (0750):
drwxr-x--- 6 awstats adm  4.0K May 22  2009 /var/cache/awstats/
drwxr-x--- 2 awstats adm  12K Apr  4 19:21 /var/lib/awstats/

And usual umask for data-files itself.  So, just "chgrp www-data
/var/cache/awstats/" to enable web-access.

> Your proposal - user interaction for public access:
>
> cron:   logrotate[root] < httpd > logs[root:adm]
> cron:   awstats[awstats] < logs[:adm] > stats[awstats:awstats]
> admin: (reconfigure output group: > stats[awstats:www-data])
> cgi:    awstats[www-data] < stats[:www-data] > httpd
>
> Result: Awstats stats available to all that can access web server.

Yes.  But it's just a variant.

Actually, it's a better suggestion to use the static html-pages in
/var/cache/awstats/.

> Your proposal - user interaction for protected web access:
>
> cron:   logrotate[root] < httpd > logs[root:adm]
> cron:   awstats[awstats] < logs[:adm] > stats[awstats:awstats]
> admin: (reconfigure output group: > stats[awstats:www-secure])
> admin: (configure Apache vhost with suexec or similar)
> cgi:    awstats[www-secure] < stats[:www-secure] > httpd[:www-secure]
>
> Result: Awstats stats available to isolated web vhost.

Another option.

>> Optionally, enable web-access stuff.  For example:
>> 5. chgrp www-data /var/lib/awstats
>
> Not enough: actual files need to be changed too.  I suggest to make it
> configurable which read-only group should be used.

No.  Actual files need not to be changed.  See above about umask.

But "chgrp some-one /var/lib/awstats" could be debconf'igured.  You are right.

>  * debconf asks for group
>   * group is created if not existing already
>   * awstats user is added to group if not member already
>   * answer in /etc/default/awstats
>  * awstats cronjob try to use configured group
>   * use own group if no group declared in configuration
>   * fails silently if group missing or awstats not member

Yet, it's too complex.

Debconf options: 1) Use own group (awstats).  Local admin have to tune
manually access for awstats to logfiles.

> As mentioned above, adding awstats to adm group is safe in itself, but has
> the potential risk of leaking other adm-accessible data when awstats output
> is also shared with other groups.

2) Use system group adm (say, USE_ADM=yes in /etc/default/awstats).
It's that can be configured not-really-secure-by-default
(/var/{cache,lib}/awstats - belongs to awstats:adm, permissions 0750).

This way, parsed statistics and html files are accessible for
awstats:awstats or awstats:adm.

> I suggest to use your proposed design (i.e. not try to provide a really
> secure design that works out-of-the-box, but also only enable your
> almost-safe design only as an opt-in):
>
>  1) Have the cron job silently fail if logfiles are not accessible
>    (as should be the case today already, and mentioned above too)
>  2) have debconf ask (default=no!) if awstats should be in adm group.
>    * Mention that this may indirectly weaken the discretion of the
>      adm group.
>    * Conditionally add awstats to adm group based on answer
>    * Store answer in /etc/default/awstats

I'm disagree.  Just an option USE_ADM=no (awstats group) or "yes" (adm group).