Re: secret data for php pages
On Wed, Jun 07, 2000 at 09:05:29PM +0200, Robert Varga wrote:
>
>
> On Wed, 7 Jun 2000 cfm@maine.com wrote:
>
> > On Wed, Jun 07, 2000 at 08:23:18PM +0200, Robert Varga wrote:
> >
> > > > Store the mysql connection information in a PHP file in the webspace. I
> > > > often create a file db_config.php3 and it looks like this:
> > > >
> > > > <?
> > > > $dbhost = "localhost";
> > > > $dbuser = "someuser";
> > > > $dbpasswd = "somepassword";
> > > > mysql_connect ($dbhost, $dbuser, $dbpasswd) or
> > > > die("Unable to connect to mysql server ($dbhost) ...");
> > > > ?>
> > > >
> > >
> > >
> > > The problem is that anyone who can put up a php page can download every
> > > php page _source_ there is on the webserver (see my initial post).
> > > Therefore the password is retrievable this way.
> >
> >
> > Nor would the above script be persistent no? I don't do any PHP.
>
> It would be persistent if invoked from the mod_php3 and not from php3 cgi.
>
> >
> > What we do is generate an initial connection to db when server starts
> > up as root. The server then changes uid/gid to nobody:nogroup. Now
> > that is with WN. Hardly stock debian setup. ;^) Nor do we let users
> > onto the machines with that setup; it's staff only. Period.
> >
>
> How can this be carried out and what is WN? :)
WN is another web server. We use that and Roxen. Both will start up
as one user and then change uid/gid to another. This give you an opportunity
to connect to db **before** the change. Presumably, you could
do this with any server. They all start as root, at least if they are
starting at boot. Make your db connection before changing uid; just how
you pass that connection handle to php, well....
Frankly, if you have users running php scripts like this they should be
on their own boxes. We'd never let them on a shared server. If your staff
is writing the scripts, then don't let users modify them. chown staff.
> > As an alternative, you might be able to set server id read only depending
> > on how much updating and run the updates suid, etc....
> >
>
> I don't understand this part, but reads are also dangerous, think on
> retrieving other user's sensitive data :)
There are a lot of different degrees to that. You may not care who
reads, but only who updates or you might care who reads. There is no
general solution; you need to establish your own policy. If the data is
truly sensitive, than simply depending on server hostname is unrealistic;
you would have additional passwords, ip restrictions, cookies.... We
use all of those. A cookie user will see only data qualified
"WHERE cookie_id='etc'", an intranet user will see data (or pages)
conditionally served to IP range, so forth and so on. You probably can't
do that with php but need some sort of page building infrastructure.
--
Christopher F. Miller, Publisher cfm@maine.com
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
1.207.657.5078 http://www.maine.com/
Database publishing, e-commerce, office/internet integration, Debian linux.
Reply to: