Michael A. Peters wrote:
Robert Cummings wrote:
Michael A. Peters wrote:
Robert Cummings wrote:
Michael A. Peters wrote:
Manuel Aude wrote:
I'm giving a PHP course next semester (3 hours all saturdays for 22
weeks)
and I just realized that PHP 5.3 is coming very soon (2 days now!).
So, my
plans of teaching PHP 5.2 are starting to change, and I think it's
a good
idea to teach them 5.3 already.
While the majority of the students use Windows, I'm aware that a
vast amount
will be using Ubuntu/Debian (and some use Gentoo, Fedora and Arch)
distributions of Linux, so I'm hoping there won't be too many
problems on
installation. I don't want to waste the entire first class fixing
installation problems, because that kills the student's motivation.
The course starts on August, but I'm preparing it during the last
two weeks
of July. You think that installation packages will be bulletproof
by then?
Or should I just teach 5.2 and wait for another semester before
starting on
5.3? I mean, most hosts will remain with PHP 5.2 for the rest of
the year,
so I'm a bit confused on what I should do.
I'm just a university student that wants to spread PHP, for I've
been using
it for many years now =)
Thanks for the advices,
Mamsaac
Many hosts are still on php 5.1.x (IE RHEL based hosts).
I would be worried that many popular classes and apps might be
quirky under 5.3.
I've not played with it at all, and probably won't for some time,
but I've been bitten by that more than once.
Nice thing about 5.2.x as far as linux goes anyway, installing it is
cake from the package repositories. Using package repositories for
php installs is suggested as security fixes can be updated with ease.
As someone running a newer version of php (5.2.9) than what my
distro ships with, here are some of the issues:
A) I needed to create packages so that I could RPM install various
stuff, like Squirelmail, etc. - and get the security updates for
them from my OS vendor (CentOS or EPEL repods). So to do that, I
used the Fedora src.rpm.
B) When building php rpm's on my system, the %check portion of the
spec file (runs make test I believe) fails sometimes if there is an
existing php install. To solve that, you have to build it in mock.
C) Mock needs a lot of disk space and will download a lot of
packages, if you don't local mirror the update repositories, it can
be really time consuming. Furthermore, occasionally the build list
for mock is broken making it un-usable for package building.
I have to use 5.2.x because I need a pecl extension that does not
work with 5.1.x - and building rpm myself lets me add suhosin patch
(to the fedora spec file) but unless your Linux students want to do
absolutely everything php by source and not have anything installed
from the package managers that rely on php, I would highly suggest
that they use whatever version of php their distro of choice has in
its stable repositories.
-=-
Since you are teaching students, one pet peeve of mine that I see in
web app after web app after web app - they have an admin interface
that writes a php file which the app then parses as php. Often they
even instruct the person installing the web app to have 777
permissions of directories and/or files within the web root.
There's a better way. Either store the configuration settings in a
database (obviously can't store database connection setting in the
database ...) or store them in an xml file, not php.
You can write and read the xml file with any number of existing php
functions. And the config file should not be in the web root,
nothing the web server can write to should be in the document root.
Applications (like Gallery and I think joomla and wordpress) often
want write permission to the document root so they can have a web
interface to install/update their modules - but it creates a
security risk. It's better to install the modules you want from a
distro vendor repository so you can keep them up to date that way,
and hence, it's better to use a packaged php install so that the
dependencies are met.
Sorry for rambling, but the trend of web server having write
permissions to files the web server then executes (and often in the
web root) is a trend that needs to stop. So flunk the students that
do it ;)
And how do you propose people get around open_basedir restrictions
which is common in many Plesk environments?
There is nothing wrong with having the above mentioned write access
if it is properly protected.
Nothing wrong other than any vulnerability in apache (or a module
apache loads or cgi/server script code) that allows a malicious user
to write data as the apache user can now do so inside the web root
where they can then request it causing php/perl/python/whatever to
execute the code they just wrote.
This is fear mongering.
No. It is not.
The web root should be read only.
Please cite references as to why it should be read only. Please explain
why the feature exists if it should not be so.
I could make the same argument that making use
of a webserver opens you up to any vulnerability in the webserver that
may provide access to the entire filesystem. The intended purpose of the
webserver is not to allow such access when configured properly, and so
it is an exceptional circumstance when such security is compromised.
These compromises do happen, which is why the web root should be read
only to the web server and any data the web server has write access to
should be validated before it is used.
And the operating system?
It isn't hard to do.
It's hard to create a helpful application when fort knox is your
delivery location. I'm not saying there's a problem with Fort Knoxes in
the world, but this isn't necessary for everyone. if it were we wouldn't
have banks, we wouldn't have credit unions, we'd all be going to Fort
Knox to make our deposits and withdrawals. One size does NOT fit all.
It
is common practice to use .htaccess to lock off sensitive areas of a
website such as where any writeable documents live. if you set
permissions appropriately on the filesystem then the web process should
only be able to read those areas where you don't want it to write.
Writeable and executable permissions may pose a special problem, but one
can merely enable the rights when updating the modules and revoke them
afterwards.
Yes you can, but people don't.
This doesn't disqualify the process. I am not my brother's (or sister's)
keeper.
You can also have specific directories outside the web root where the
web server has write permission for things like file and image uploads,
and use a wrapper inside the web root that is used to read and send (and
validate when necessary) the data as needed, and avoid the risk of write
permission within the web root.
Yes you can, but this isn't always available depending on the setup
within which you are working.
Just as an example, I was looking for a simplistic blog to add to my
website. The install script didn't even work because it used system and
exec calls which many servers (including mine) do not allow.
This is a problem with your setup. I make use of exec() calls often
enough when within a Linux environment. If this is a known parameter of
the application, then it is not incorrect to use exec(). It is common to
build upon existing shell binaries.
What it did
with those calls is create directories that were 777 permission inside
the web root. One directory for flat file comments (odd, as it used
MySQL for the actual blog entries, why it didn't have a table for
comments I don't understand) and one for images. No validation of the
images was done, not even by extension, meaning I could upload evil.php
and it would happily upload and be placed inside the web root, allowing
me to then call the file from my browser and php would happily execute
the code.
A specific instance of a poorly designed application does not stand as
the model for all applications. There are countless examples of bad
programming and exploits at pretty much every level of a system. These
do not suggest we should not use computers.
Yes, it was crap code, I've now started writing blog software of my own
as that seems faster than fixing any of the apps I found - but the
reality is that there's a lot of crap code out there, and there's even
good code that has vulnerabilities (including binary php modules), so
one should have a strict policy of never having directories or files
inside the web root that the web server has write permission to.
Why? You still haven't given a good reason. I am the master of my
environment, if I know what I'm putting into my environment then who is
to tell me my setup is wrong? Perhaps you should be suggesting something
else like being more careful when choosing your applications, or as you
appear to be doing... roll your own. Every operating system has
vulnerabilities, are you going to stop using one? Maybe you're going to
roll your own.
What if a current (or future) bug in FileInfo exists that allows a
carefully crafted file to be reported as a file type it's not? Then even
validating the file type could result in arbitrary code on the server
that could potentially be executed as part of an attack.
What if a meteor hits my house tomorrow. I'm not about to move my house
just in case. An alternate location may be just as bad. I live in a
world of reality, mental discourse and entertaining the "what ifs" of
the world is fun and all, but at the end of the day, I presume
developers have done their job and my environment is bug free. Otherwise
I await a speedy patch to apply to my environment.
Web server administrators should not allow the web server to have write
permission to the web root and web app developers should not instruct
the user to install software with write permission in the web root.
You still haven't given a good reason except that something might be
buggy. Please give a better explanation. If you don't like what an
application is doing then don't install it, or add the necessary steps
to the process to lock it down when such access is not needed.
Installation of apps may need a slightly more detailed readme and
require a few extra install steps, but people who can't read and follow
the instructions have no business running a web server, and if the
application is good, it will sooner or later be packaged by a quality
package repository making secure installation a snap.
The same argument can be made that people who can't lock down their
system properly have no business running a web server. You're trading
apples for oranges, except the only criteria is fruit. Why will it be
packaged by a repository if it is good? Not everyone wants to offer
their stuff as a package in apt or yum. Not everyone is open source.
Don't make wide sweeping assumptions about what may or may not happen.
Updates to web app modules can be handled by an update manager, such as
yum or apt, from a gpg signed package repository.
Again why? This is personal preference. I like apt and yum indeed (not
so much yum though), but I still download the PHP, MySQL, and Apache
tarballs and compile and install by hand. I do this for quite a few
applications on my system.
I don't know what package managers there are for windows, but vast
majority of web applications that need module (or core) updates are
packaged already for Fedora and Ubuntu and even many for RHEL (in EPEL)
in their mainstream repositories, and updating them can even be
automated, eliminating the need for manual updates through a web
interface that require insecure write permissions and usually do not
have any kind of signature checking on what they download and install.
So with some hand waving and fluttering of your eyes you've eliminated
(or at least completely ignored) all the Windows machines in the world.
Nice. I prefer Linux over Windows but I certainly don't exclude Windows
from consideration-- in fact I do some work within Windows using fastCGI
PHP through IIS.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
