Re: chroot, Doctrine, ZendFrameWork

Tony Cairns gave an awesome session on chroot. If you are running
your public facing web services on the root of your system, STOP IT!.

Rob,

Just to clarify, is the warning to STOP IT because of a need to protect
PASE from being "hosed" by a user having "root" privileges?

Tony gave an awesome demo of how to create separate environments for each
developer and web services. If you get hacked, back up current chroot,
delete chroot, create a new one...

Coincidentally, this week I set up a Linux server at http://aws.amazon.com/
to use as an FTP gateway to Amazon's S3 storage, which we're interested in
using for offsite storage of our daily backups.

Of course, in a *nix world you pretty much build your application
environments by downloading useful components from repositories. I
downloaded, installed, and configured an FTP service.

However when I tried to access the service from our IBM i system, some of
the FTP commands like "mkdir" didn't work. No error messages to speak of...

I "assumed" that my FTP user profile lacked authority to the "root" file
system. I began looking for a way to grant permissions to my user ID and
came across the "visudo" command. I played with it, but being a Linux
dweeb, I pretty much hosed my Linux VM.

The best "advice" I could get from the Internet was to start over by
creating a new VM instance from a Linux image - which I did.

The real problem was that my user ID lacked privileges which are configured
in the FTP server - not really having anything to do with Linux OS
privileges.

Live and learn.

By being in a chroot, no one can ever get to your database and your
business logic.

I don't understand that statement. Isn't the idea of setting up an
"environment", so that people CAN get to their databases and business logic
(through their applications)?