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

Mon Apr 13 10:25:54 UTC 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Apr 13, 2009 at 12:26:47PM +0400, Sergey B Kirpichev wrote:
>> >By default awstats user has NO access to log files (adm group).  
>> >Only when a local admin chgrp to awstats them (explicitely) - then 
>> >awstats will have a readonly access.  It's simple and a bit easy to 
>> >support. No new (buggy ;-)) wrappers for awstats.pl in 
>> >cron.d/awstats.
>>
>> There is no flaw in the packaging itself, but you take only a single 
>> workflow into account, and for that workflow you tell the admin to 
>> weaken security.
>
>How??  It doesn't weaken anymore.  Anyway awstats user need an access 
>to logs for log parsing.  Exactly that's shall be done by "chgrp 
>awstats /var/log/apache2/*" (by tuning logrotate settings, actually).

Sorry, you are right: Security is intact, only flexibility is weakened.

This is your approach (please correct me if I am wrong:

logrotate[root] < httpd > logs[root:awstats]

awstats[awstats] < logs[:awstats] > stats[awstats:www-data]

awstats[www-data] < stats[:www-data] > httpd

It won't work out of the box: It requires changes to a logrotate script 
not owned by our package, so cannot even optionally be automated by us.

When working, raw logfiles are only usable by awstats - other packages 
(e.g. alternative log analyzers, perhaps even security surveillance) 
cannot concurrently access them without even more custom changes.

This is my approach, improved to not use root access but another user 
member of both adm and awstats groups ([:awstats] means read-only by 
members of awstats group, writable only by same user):

logrotate[root] < httpd > logs[root:adm]

awstats-adm[awstats-adm] < logs[:adm] > logs[awstats-adm:awstats]

awstats < logs[:awstats] > stats[awstats:awstats]

awstats[www-data] < stats[:www-data] > httpd

It won't work out of the box: Stats are generated but accessible to 
noone by default.  Changes needed are possible to automate, however, as 
they involve only groups memberships and/or our own config files.

When working, raw logfiles are untouched, so usable by other packages 
too.

>> Here's another scenario: Multiple users have shell access to accounts 
>> also used for webhosting. Each account is sealed in that users cannot 
>> read each others content - some might contain .htaccess files or 
>> other security-related files.
>>
>> For that scenario you cannot tell the admin to make logs readable by 
>> www-data.
>
>And I don't do so.  Instead, I just suggest to make it readonly 
>accessible by awstats group.
>
>Parsed stuff is accessible by awstats:awstats only by default.

Correct.  Sorry - I did not understand correctly.  Please see above if I 
understood correctly now (and how I still consider it inferior)

>> I would like awstats to support multiple virtual hosts securely.  Not 
>> now, but later.  I would like to do it right, when we bother our 
>> users with restructuring the central config files.
>
>Right now we can suggest (in config examples) the following layout:
>/var/lib/awstats/raw/ - *.txt or *.xml database files
>/var/lib/awstats/html/ - *.html reports (static)
>
>Local admin can (a) "chgrp www-data /var/lib/awstats/" to allow a web
>access or (b) copy&chown (in crontab) right virtualhosts stuff from
>/var/lib/awstats/html/* to the right webhosting user.

Yes, we can throw all sorts of files in as examples.  Examples are 
unreliable, it is something that we do not support.

With my proposal we can extend our *supported* routines to support 
several approaches to virtual hosting.  And we can extend our 
*supported* routines to automatically enable fully working, 
web-accessible stats (yes, I _do_ want that to be possible, I just don't 
want it to be the default).

>> Oh, and by the way: Are you aware that when you now dropped the check 
>> for existence of logfiles in cron job, awstats is invoked each 10 
>> minutes even there is no webserver installed.  not nice to system 
>> ressources.
>
>But _all_ log parsing configuration stuff goes to /etc/awstats/* files.

I am not talking security here.  I mean that installing a package that 
is consumes memory and CPU every 10 minutes even if for no use (and 
silences warnings that it is of no use) is not nice.

If I recall correctly, the bugreporter originally complained about 
having to maintain logfile path multiple places. Not about the script 
being tied to a specific path.

With your approach we do not need to know the location of the logfile, 
we trust AWStats do handle that.

With my approach we need the location, possibly in multiple scripts, so 
it makes sense instead to save the location in /etc/default/awstats.

We can later extend AWStats itself with an option that simply spits out 
the path(s) it will be expecting as input, that we can then use in our 
preparation scripts.  But I suspect this won't be necessary.

>>  I would prefer to instead get the logfile path from
>> /etc/default/awstats with a comment there that central awstats routines
>> can be disabled by commenting out that path.
>
>It's not so easy to do for multiple virtual hostings.  Or if there is a 
>serveral webservers (e.g. fronted/backend).

I agree that there are many many ways to do virtual hosting, and we 
cannot expect to ever support them all.  But it _is_ possible to support 
some of them, also without complicating matters too much.

>AWstats should fire error to stderr if logfile doesn't exists.  It's a 
>problem for local admin, we would't hide one (Yes, I now that it sends 
>hundreds of mails sometimes...).
>
>I suggest just comment out the default cron entry.

Yet another thing the local admin needs to do manually which we cannot 
later automate :-(

It is better to provide master config below /etc/default than requiring 
the admin to edit multiple configfiles in different formats.

Also, files below /etc/default must use a specific format that we can 
later automate and provide a debconf interface for.

Would be _very_ nice if we some day could make it possible to preseed 
awstats for use out-of-the-box at various security levels.

  - jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknjEzIACgkQn7DbMsAkQLjfDgCdHnjyxnI4dSc7sylScR3XtR84
qhsAn25gqu0TOeGvQ/GyTB93MEoJbtvN
=Oj1T
-----END PGP SIGNATURE-----