All these solutions are depending (mainly) on having a dedicated server,
which I believe would not be the case for 90% of the users on here
(don't shoot me if i'm wrong).
So far, I can't see how the problem can be solved. My host does not
allow telnet/ssh at all which sounds like a good thing!
On Tuesday 23 October 2001 23:33, Kurt Lieber wrote:
Sorry -- but you're wrong. If you've got php loaded as an apache
module in a shared hosting environment, then any file that apache can
read, I can gain access to through a simple FTP account and a
well-constructed php file using fopen().
On Wednesday 24 October 2001 00:30, you wrote:
What we
really need is an expert here to give us the low-down on the best way to
accomplish the best security given regular tools.
There isn't a way to solve it within the constraints you've mentioned (shared
server at a hosting provider,
On Wednesday 24 October 2001 16:42, Kurt Lieber wrote:
On Wednesday 24 October 2001 00:30, you wrote:
What we
really need is an expert here to give us the low-down on the best
way to accomplish the best security given regular tools.
There isn't a way to solve it within the constraints
Move it outside the document root
or put a .htaccess file inside the dir to deny access. This will still allow
system access but will prevent other fopen.
M:
In a PHP application using MySQL i have to connect the database using
$iDBhandle = mysql_connect( $sDBhost, $sDBuser, $sDBpsw );
On Tuesday 23 October 2001 11:13, Andy wrote:
Problem is, that I cannot see any solution to protect the value of $sDBpsw.
Of course I wont set the value of $sDBpsw in the same PHP script. I do
that including a file pa/pa.php (protected area) but this file also has to
have read access to all
On Tuesday 23 October 2001 11:20, Matt Williams wrote:
Move it outside the document root
or put a .htaccess file inside the dir to deny access. This will still
allow system access but will prevent other fopen.
Either solution still allows anyone with shell access to the machine to read
your
I use proftpd, I can setup a chroot for the user that logs in, chroot them
to their vhosts dir, move the mysql passwd file out of that dir. now anyone
that ftp's in can not read the passwd. as for telnet (shell) access, its
rare a user needs that anyhow, if you feel your customers do need that,
One solution is to depend upon your defaults in /usr/local/lib/php.ini
. Then just call mysql_connect() with no arguments or just call
mysql_db_query with out the connection parameter and PHP will connect
for you. If you are connecting to different MySQL servers this solution
is not appropriate.
On Tuesday 23 October 2001 12:29, Chris Lee wrote:
I use proftpd, I can setup a chroot for the user that logs in, chroot them
to their vhosts dir, move the mysql passwd file out of that dir. now anyone
that ftp's in can not read the passwd. as for telnet (shell) access, its
rare a user needs
Kurt Lieber wrote:
Regarding shell access being a security risk, ssh is far, far more secure
than FTP can ever hope to be.
This is why there's FTP over SSH, or sftp.
--
W | I haven't lost my mind; it's backed up on tape somewhere.
11 matches
Mail list logo
