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

Sergey B Kirpichev skirpichev at gmail.com
Sat Apr 11 18:56:56 UTC 2009


On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
> >1. system user awstats (cron jobs owner) in group adm
> 
> Bad, when used as a CGI script: Gives writes access from anonymous web 
> users to all adm-writable files!

Wrong, just readonly access for www-data, see below (steps 2 and 3 of
the original RFC).

On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
> AWStats analyze data that is by default readable only by admins, so our 
> output should by default also be accessible only by admins, but 
> optionally readable by others too.

You want to access web statistics from web, isn't?  Then, it must be
accessible readonly for www-data (Either generated html-files or awstats
data files, doesn't matter).  See below for suexec-like setup.

We can protect CGI-script or static html-files, by some kind of HTTP
access control (e.g., only accessible from 127.0.0.1 by default) in
/usr/share/doc/awstats/examples/apache.conf.
 
On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
> Those "others" might be the whole world, or it might be another limited 
> group than admins. So it seems to me that it is better to create an 
> awstats:awstats account (i.e. both username and groupname awstats), 
> allowing the local admin the flexibility of either adding awstats to 
> other groups or add other users to awstats group (without then granting 
> them access to all other files accessible by the adm group).
>
> It might make sense to create yet another account 
> awstats-cgi:awstats-cgi and make awstats member of awstats-cgi group. 
> Cron job can then pull log files from adm group and write output 
> accessible by CGI, without CGI script itself having access to logfiles 
> (and other adm accessible files).
> 
> How does that sound?

In my case others=www-data.

But yes, the more flexible way is:

	adduser --system --home /var/lib/awstats --shell /bin/sh --ingroup adm awstats
	chown awstats:awstats /var/lib/awstats
	chmod 0750 /var/lib/awstats

Then, for example (this looks almost identical to my original setup and
seems unavoidable for static html-reports), per default:

	usermod -aG awstats www-data

or (with suexec or dedicated web server):
	
	usermod -aG awstats awstats-cgi 

The last case looks overcomplicated for me (as per default).  But
README.Debian can suggest one.

Not bad?
 
On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
> I have very limited time, so would appreciate if others would have a 
> look at this.  To make it easier to follow progress, I recommend first 
> tightening to generate static-only output, and afterwards extending with 
> an additional CGI account (not both in same go).

It's not a big difference for me.  Anyway, for static html-generated
files we should make $DataDir/* data accessible readonly for www-data.

The main difference between CGI vs static stuff is just a matter of
the awstats.pl command line parameters in /etc/cron.d/awstats ;-)

On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
> >2. Data files writable by awstats, readable by anyone
> 
> Bad: Apache2 logfiles are carefully kept readable only by adm group by 
> default. AWStats should not defeat that by revealing its working files 
> to the world.

Wrong.  Actually, data files are readable for www-data in effect, see below.

On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
> >3. DirData has group www-data & permissions 0750
> 
> I agree that permissions should be tightened to not be world readable. 
> But readable by www-data is arguable somewhat equal to world readable, 
> so that should be configurable.
 
Right, defaults to chmod 0750 $DirData & chown awstats:awstats $DirData
sounds better, see above (so, for suexec-enabled setup it may not be
www-data readable).  But I've no simple solution to avoid this, if
the static reports will be a default.
 
> >4. crontab examples (I guess, we can install awstats-update
> >script & manpage, see bug #255938):
> >cat >> /etc/cron.d/awstats <<EOF
> >#MAILTO="root"
> >#30 7 * * * awstats /usr/local/bin/awstats-update
> >#30 7 * * * awstats /usr/lib/cgi-bin/awstats.pl -config=site.com -update > /dev/null
> >EOF
> 
> Examples are examples: We do not support them, and do not use them.

Ok.  But we should change www-data -> awstats in the cron.d snippet.

On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
> Let's write to /var/lib/awstats/... and provide config snippets for web 
> servers redirecting /awstats to use that directory.
> 
> While we are at it, those snippets should then by default be protected 
> to e.g. only accessible from 127.0.0.1 (like CUPS and other 
> administrative web services).

Agree.

On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
> >If user wants AllowToUpdateStatsFromBrowser=1 (disabled by default), we
> >can suggest suexec-like stuff in README.Debian.
> 
> Well, we can try to document that, but if we start by protecting direct 
> access to adm-only files, it gets messy to unlock it again.
> 
> I'd say we should first tighten security, and then (maybe!) afterwards 
> try documenting how to weaken security.

Right.  But my point is that dedicated user for CGI-access -- just too
complicated setup for default.

PS:
I suggest to make a release (as you wish) before any big feature
changeset.  There is a number of tiny fixes/improvments.



More information about the Pkg-awstats-devel mailing list