Re: [Phpwiki-talk] Security (was: Re: new admin/ directory)

[Jeff D. <da...@da...>]

In message <Pin...@bo...>,Steve Wa
instead writes:
>It would only be as secure for as many people out there who don't know
>there is a lib/ and I'm sure lots of script kiddies read Freshmeat on a
>daily basis... 

With apache if one creates a lib/.htaccess that reads:

order allow,deny
deny from all

Then no one can get at anything in lib via http.  (The same should be done
for templates/.htaccess too.)  Other httpds (including  at least Netscape's
and NCSA's) offer similar abilities, though the actual directives may differ.
I'd be surprised (I often am) if most httpd's don't allow the user some kind
of similar control.

When I put together HammondWiki, the first thing I did was move the 
wiki_*.php3's
into a non-readable lib directory.  In my case (apache) this required no
source code tweaks at all, as I set the php include path in
HammondWiki/.htaccess.

>Any changes that mean something won't work "out of the box" is going to
>meet stiff opposition from me :-) 

I agree completely.  That's one of the advantages to using PHP in my opinion.
On the other hand, I'm sure there are plenty of non-portable things you can
do in PHP --- and I don't have much experience other than in an apache
environment.

It might be interesting to do a user survey to find out just what environments
phpwiki is being run in.  What do you and Arno deal with?


>> When apache is configured to do external authorization,...
>
>(Is that, btw, the same as the .htaccess file?)

Uh, sort of.  One needs the following (or similar) directives in http.conf
or an .htaccess file.  (These directives can be disallowed in .htaccess files
by http.conf.)

 # User and group password databases.
 AuthUserFile /some/password
 AuthGroupFile /some/group

Then either in a <Directory> (or similar) section or in .htaccess you put
something like:

 require user dairiki

Then only dairiki can access that stuff.

The confusing thing is that once you've set an AuthUserFile (and I can't  
find a way to unset it locally in an .htaccess file), even in a directory
with no 'require' directives (ie. no authentification required), neither
the username nor password will ever make it through httpd.

(Confused yet?)

>> Files and directories which are writeable by through httpd make me 
nervous,...
>
>Whenever I've added something that means "the server can write to it," be
>it a DBM file or a directory, I think very carefully about it. Being able
>to dump Wiki pages to a directory doesn't sound too dangerous, since the
>input has to be a dbm file (or it fails completely).  ....

Yes, it's seems pretty safe.  I can think of any exploits other than
filling the disk DOS type attacks (which are possible anyhow...)

>Also, a friend recently asked me what's to stop him from uploading a
>uuencoded warez file and I said nothing; but maybe we want to set a hard
>limit on page sizes anyway, like 1M or maybe 500,000K. That could be a
>define() in the config file and a check on the size of the page in
>wiki_savepage.php3. 

Good point, a hard limit sounds like a good idea.  I would make it considerably
smaller than 500,000K (or even 500K :-).  It would be interesting to find the
biggest current Wiki page.

>> Another slick alternative might be a PHP script which creates a tar- (or zip
> -)
>> file dump of the wiki on the fly
>
>THAT is a very interesting idea...

I'll look into it a bit more.  Compression will be a problem without local
temporary files (which I suppose aren't a big problem.)  (Of course compression
will be a bigger problem if your PHP doesn't have zlib...)

What's the best output format?  Tar?  Or zip for windows friendliness?
Or something else I haven't thought of? 

>> Maybe wiki_dbmlib can do this automatically every once in awhile?
>
>It would have to be an admin function because if you decide that the first
>user after 4am every day triggers the rebuild, you are counting on that
>user to not stop the transaction before it's done. (i.e., click the "stop"
>button and interrupt the rebuild.) That makes me nervous.

See ignore_user_abort().  See also register_shutdown_function() which allows
you to continue executing PHP after the html output stream has been closed.
(There may be other better ways to do this, but I don't know them.)
(There's also flush() which flushes the output, allowing you to add to it 
later.)

I was thinking of an update count stored in the DBM.  When it exceeds a
threshold, the DBM gets rebuilt.

Jeff