> I am a system administrator and currently we are playing to migrate all
> our CGI (written in C) to php! But playing a little with php i got
> worried about how services that need to keep username/password are
> handled by php, for instance:
For starters, you *could* have PHP running as a CGI wrapped by suExec
(http://apache.org)
Performance, however, would be not-so-hot, particularly after custom C code
as your previous experience.
Rumor had it at one point that Apache 2.0 would allow Modules to execute in
a similar fashion to suExec -- Whether this feature has survived
development/debug/QA phases is unknown to me. But it *might* be worth
checking out. WARNING: You'd be way past the envelope of tested source
code at that point. Not just with Apache as Beta software, but with
PHP/Apache/MySQL interaction. OpenSource QA mostly consists of quantity of
users pounding on stuff, versus a planned organized QA team.
You *could* write a tiny C-module using PEAR, or even alter PHP's source
code, to have the passord encoded as part of your PHP Module binary. Your
username/password would then be buried somewhere in the binary of that
module, so only a C disassembler would get it out. I *think* libphp4.so
just needs to be executable for Apache, right?...
Many admins set up different username/passwords for MySQL, depending on what
"classes" of users need select/update/insert/delete access to which
tables -- And the one username/password combo that is for general everyday
access through your public site is stored in a file that the PHP user
(default 'nobody') can read, but is in a directory tree that is not in the
web tree and that other users cannot 'cd' to. PHP can
http://php.net/include such a file, even though it is not visible in the
web-tree via a browser, if the include_path is set properly in php.ini.
Still, other users on the same server can read that file using PHP or Perl
or anything else than can run as user 'nobody', so it's not great
protection.
Another option would be to buy the Zend Encoder, and encode the file that
contains username/password info. Rather expensive for what you need right
now, but it would save you writing/testing the C code to bury the
username/password in a large enough block of binary, and you can move on to
your "real" application. Of course, if at some point you want to install
PHP code on somebody else's server, or just keep a lot of files on your own
server protected, the Zend Encoder price becomes more reasonable. Again,
only somebody with a lot of time on their hands, a thorough knowledge of the
Zend engine, and a disassembler is going to be able to reverse-engineer
this.
Still, if they want it bad enough, they *can* -- There's pretty much *no*
*way* to have your web server capable of reading/executing a file, and yet
not have some other user on that machine capable of doing the same to
masquerade as that MySQL user, if they work at it enough. It will be as as
good as your CGI programs were, but no better. Well, maybe a little better,
since C crackers/disassembler-experts exist, but I don't think there are any
ZendEncoder cracker specialists yet...
> All our CGI programs execute sql queries to a mysql server, they
> contains the user name and password in order to login into the database.
> Since these programs need only to be executed its read flags are turned
> off. I need such a funcionality with php, but how can this be done?
It seems to me though, that the barrier difference between nobody-executable
and nobody-readable is not *that* different: If I can write a Perl/PHP
script to execute your connect.cgi, it ain't all that more difficult from
being able to read the username/password in your connect.php. Yeah, I have
to write a little shell script. Not that big a deal, really, in most
real-world scenarios.
> PHP scripts not owned by the user that runs the web server are required
> to have the read flag for all tuned on, ok? this makes its contents
> readable by all my system users, right ? So how to put user
> name/password information into such script in order to get it accessing
> mysql, but without allowing any other user to get into its contents and
> reading login/password information ?
It doesn't have to be *world* readable -- You can chown -R your site to be
the user that PHP runs as, and chomd -R 400 it. See <?php phpinfo();?> to
find out what that user is, and edit httpd.conf to change it with "User"
directive. So now, only people who can su to 'nobody' or who have access to
write PHP/Perl/C code on your server are able to snarf those passwords.
Let's face it -- If they can write PHP/Perl/C code and execute it on your
server, your MySQL passwords for data that web-surfers can read is probably
not your biggest worry.
Also, check out "safe mode" That makes it harder for one user on a shared
server to read another user's files with username/password info in them.
This is more for use in a VirtualHost ISP environment, which I get the
feeling you're not, but I could be wrong.
--
Visit the Zend Store at http://www.zend.com/store/
Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
