Re: SF.net SVN: squirrelmail:[13777] branches/SM-1_4-STABLE/squirrelmail

On tiisdei 2 Juny 2009, Jonathan Angliss wrote:
> >@@ -2,4 +2,5 @@
> > Deny from All
> > Allow from 127
> > Allow from 10
> >-Allow from 192
> >+Allow from 172.16
> >+Allow from 192.168

This is still not a complete specification of RFC 1918 addresses, although it 
doesn't include publically routable ones anymore. I've updated it now to be 
consistent with RFC 1918.

> Currently we point the web root to the base of the SquirrelMail
> directory, instead of the src/ directory.  Currently that's because
> plugins reside in the plugins/ folder, and may require some output.
> The user that jumped on IRC questioned why so many PHP scripts can be
> executed without a need to.  Whilst I generally agree that the idea is
> that you should be able to just drop and run SquirrelMail without
> having to tinker with any paths, I sometimes wonder how difficult it'd
> be making all the subdirectories outside the web root.  I also
> question whether this is one of those cases of "security by
> obscurity", but it does lead to improve security in that some scripts

I don't think it is - blocking access to things you don't need access to in 
the first place is not obscurity but just sensible. It's obscurity if you can 
in fact access it but it's made a bit more difficult to find out.

> that don't need to be executed by the user, should not be executable.
> The example provided by the user on IRC was the themes folder.  Whilst
> they're harmless, they can be executed as a script, and it only takes
> small typos to introduce bugs.
>
> We only provide a limited number .htaccess files in the directories,
> should we consider expanding it, as well as increasing the options
> included (no listings and such)?  Do we want to consider the idea of
> bumping stuff outside the web root?

It would be altogether better if it would be possible to set the web root to 
say the src/ dir and make all of our other scripts unreachable. However, we 
cannot easily incorporate that into the current layout. There's the following 
problems:
* Plugins may ship pages that need to be accessed in an URL directly;
* images are outside of src/
* We do assumptions on the fact that you can link to say 'src/login.php' or
  similar, or make path calculations based on that.

Those are solvable but that would be strictly devel-only, because it means we 
need to break the way plugins currently function.

One solution may be that we keep the current plugins dir where it is, and 
forbid the supplying of functionality as a separate page. Instead, plugins 
can provide a function to some kind of new (?) hook that allows that specific 
functionality to be called from a script under src/.

The images dir can just be moved. The assumptions made on URLs can probably be 
resolved within our code itself, although it might take a non-trivial amount 
of refactoring.


cheers,
Thijs

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get

-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: [email protected]
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAABAgAGBQJKJMw0AAoJECIIoQCMVaAcF6QH/3tF67FKDtzYQPJyt9oPB/V1
FreBghQuiE3iYKnTG29xI+k+fTpiDDz4L8S0IzYQhbnIb+5grZ0ZtX8+cVn3oxY1
GYwHlQBlmxfCKu5AJ0f3LzcDm40yfjo9sc8/H+qbtmzcdua9jITGT+uTgy07ACKF
x8c7e3C2cM7RbDes9P4ibx3yDPjZ5x38qIDBhajOYCvcW4ZstksIHrqu5Lbfl4Op
fpca0VGrFvj6z9pPksIcf/yXUg3rf/jxjc3MlUyQcwlDE4Vd275OySzxH3qCKDQ0
08rkce6rdU3e8GqCj1QHWygvEgDieL34zSaRJzCrMMecH8GDsIUI7ILY6BQ5jPk=
=fOTi
-----END PGP SIGNATURE-----