From: Jeff D. <da...@da...> - 2000-07-06 16:20:35
|
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 |