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

[Jonas Smedegaard]

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

On Mon, Mar 09, 2009 at 10:37:14PM +0300, Sergey B Kirpichev wrote:
>Ok, there is some parts of my setup.  Please, comment, if we can adopt
>anything for the debian package.
>
>By default:
>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!

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.

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?

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).


>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.


>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.


>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.

Do you mean to say that they should not be examples, or do I not need to 
care about those changes, or did I miss your point?


>Or configure it to build static html files by default?  Then
>web-readable html should be placed outside of DataDir in cron job
>(/var/www/awstats/ seems fine?).

Please make it static by default!  Even if it breaks current systems, it 
would be a big improvement for AWStats to be much safer to use!

Writing to /var/www is messy, and even if it is not declared yet in 
Policy, I suspect that at some point it will be: /var/www should IMHO be 
owned by the local admin, not by packages.

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).

I have similar snippets prepared for sympa (and debconf questions to go 
with them, asking if they should be used or not), so I can have a look 
at that - as soon as the package is changed to store static output 
somehwere below /var/lib/awstats, readable only by www-data.


>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.


>Upgrade...  Well, we just can't automate it :-(  README.Debian suggests
>too broad range of setups.  Anyway, default DataDir created only in
>postinst script...  

I believe we can automate upgrades from current packaging to one 
generating static output.

In reality, since current packaging always required changes by the local 
admin, the local admin will be bothered with standard conffile dialogs 
and should accept the new defaults (or base any customizations on the 
new files rather than keeping the old customizations).  But that is 
acceptable - and the only possible way: We are not allowed to automate 
"upgrades" of user-edited config files!



Kind regards,

  - 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)

iEYEARECAAYFAkngj7YACgkQn7DbMsAkQLhT0ACgkQMbRGeSopCkO9cAxhro9h7Q
9SAAn0QejuiqY0bewQPJJ8M9YONqb5e/
=1qoY
-----END PGP SIGNATURE-----