[SOLVED] PHP code nothing happens when htpasswd issued

qwertyjjj · 08-14-2009, 04:07 PM

ANy ideas why htpasswd doesn't do anything here?
All the other parts of the code are run successfully.
Nothing from $ouput either

Code:

#! /usr/bin/php
<?php
# CONFIG VARIABLES
$host = "remote-server";
$database = "db";
$tablename = "tbl";
$user = "usern";
$pw = "pwd";

# PHP MYSQL CONNECT
$link = mysql_connect($host, $user, $pw);
if (!$link) {
die('Could not connect: ' . mysql_error());
}
$db_selected = mysql_select_db('squid', $link);
if (!$db_selected) {
die ('Can\'t select squid : ' . mysql_error());
}

# DEFINE A MySQL QUERY
$query = "SELECT user, password, enabled, customers_id FROM passwd WHERE UpdateOnNextCycle=1";

# EXECUTE THE QUERY FUNCTION
$result = mysql_query($query);

while ($row = mysql_fetch_array($result, MYSQL_NUM)) {

#if enabled =1 then add the user
if ($row == 1 )
{
#htpasswd command add
system("htpasswd -b /etc/squid/squid_passwd ".$row[0]." ".$row[1]);

}

#if enabled =0 then delete the user
if ($row[2] == 0 )
{
#htpasswd command del
system("htpasswd -D ".$row[0]);
}

#after which we update the UpdateOnNextCycle flag to 0 and set UsedDemo to 1
$result_update = mysql_query("
UPDATE passwd
SET UpdateOnNextCycle = 0,
UsedDemo = 1
WHERE customers_id = ".$row[3]."
");
}
?>

jlinkels · 08-14-2009, 06:28 PM

Best is to use the exec() call and catch all output of exec() and print it out to examine.

My first guess is that your passwd file is not writable by the Apache process. This runs in www-data context, whil it is highly unlikely that www-data is allowed to write into /etc/squid/.

Either you make this file writable by www-data (which is a bad idea) or you find another location to put the passwd file.

jlinkels

qwertyjjj · 08-14-2009, 08:13 PM

Quote:

Originally Posted by jlinkels

Best is to use the exec() call and catch all output of exec() and print it out to examine.

My first guess is that your passwd file is not writable by the Apache process. This runs in www-data context, whil it is highly unlikely that www-data is allowed to write into /etc/squid/.

Either you make this file writable by www-data (which is a bad idea) or you find another location to put the passwd file.

jlinkels

But I'm running the script as root so shouldn't it action it anyway?
If I have to store the password file elsewhere, then it's going to have to be under the webserver data isn't it...somewhere in /var/www/ but not open to the web.

When I use exec with some catch ouput lines, nothing gets reported:
#htpasswd command add
error_reporting(E_ALL);
$output = exec("su /usr/bin/htpasswd -b /etc/squid/squid_passwd ".$row[0]." ".$row[1]);
fwrite(STDOUT,$output);

jlinkels · 08-14-2009, 08:29 PM

Ok, running the script as root is not that unsafe, but still to be discouraged. One mistake in your script and terrible things might happen.

I see that in this code snippet you say "su /usr/bin/htpasswd..." Why is that? You shouldn't need that.

Try to call just htpasswd without parameters, you must get something back. Does /usr/bin/htpasswd run properly if you run it on the command line?

jlinkels

qwertyjjj · 08-14-2009, 08:46 PM

Quote:

Originally Posted by jlinkels

Ok, running the script as root is not that unsafe, but still to be discouraged. One mistake in your script and terrible things might happen.

I see that in this code snippet you say "su /usr/bin/htpasswd..." Why is that? You shouldn't need that.

Try to call just htpasswd without parameters, you must get something back. Does /usr/bin/htpasswd run properly if you run it on the command line?

jlinkels

It runs on the command line when I just use /usr/bin/htpasswd
Sorry, I put in su because it wasn't working but have taken it out now...no difference.

qwertyjjj · 08-15-2009, 06:10 AM

Quote:

Originally Posted by qwertyjjj

It runs on the command line when I just use /usr/bin/htpasswd
Sorry, I put in su because it wasn't working but have taken it out now...no difference.

Code:

 exec("/usr/bin/htpasswd -b /etc/squid/squid_passwd ".$row[0]." ".$row[1], $output);
       echo $output[0];

still nothing in the ouput. Lost for things to try now as running this from root it should work shouldn't it? Or is it because php runs as apache?

jlinkels · 08-15-2009, 08:20 AM

If you are running PHP as root, PHP does not run as Apache. Why do you think PHP runs as Apache? Are you calling your script from the command line, or from a web page?

Now include this code:

Code:

exec("/usr/bin/htpasswd -b /etc/squid/squid_passwd", &$output);
print_r (output);

and tell us what you see.

jlinkels

qwertyjjj · 08-15-2009, 08:30 AM

Quote:

Originally Posted by jlinkels

If you are running PHP as root, PHP does not run as Apache. Why do you think PHP runs as Apache? Are you calling your script from the command line, or from a web page?

Now include this code:

Code:

exec("/usr/bin/htpasswd -b /etc/squid/squid_passwd", &$output);
print_r (output);

and tell us what you see.

jlinkels

God I hate programming sometimes.
print_r gave me the clue though so thanks.
The problem was the code was never netering the add password section due to this

Code:

#if enabled =1 then add the user
if ($row == 1 )
{
#htpasswd command add
system("htpasswd -b /etc/squid/squid_passwd ".$row[0]." ".$row[1]);

}

$row!!!!!
Should have been $row[2]

The htpasswd command is still verbose though, any ideas how to turn that off?
keeps listing the help file

qwertyjjj · 08-15-2009, 09:18 AM

A potential security risk I see with this code is that as the remote mysql server is open to the internet, someone could potentially hack in and enter some stuff into the database fields. Now whilst I can check if someone has entered in their own username/password combo for free access, I don't at present checking the information in the fields. The user and password are passed straight on to the htpasswd command.

What should I be checking for in the fields to see if any dodgy stuff is passed through especially as the script is executed as root at present.
Should PHP safe mode be on for starters?Can I limit the exec dir in the php.ini just to /etc/squid/squid_passwd?

jlinkels · 08-15-2009, 10:39 AM

Quote:

Originally Posted by qwertyjjj

keeps listing the help file

If a command "keeps listing the help file" you are doing something wrong as per Linux convention.

Furthermore you are not obliged to record and display the output of a command executed by the exec call.

jlinkels

qwertyjjj · 08-15-2009, 07:23 PM

A potential security risk I see with this code is that as the remote mysql server is open to the internet, someone could potentially hack in and enter some stuff into the database fields. Now whilst I can check if someone has entered in their own username/password combo for free access, I don't at present checking the information in the fields. The user and password are passed straight on to the htpasswd command.
What should I be checking for in the fields to see if any dodgy stuff is passed through especially as the script is executed as root at present.
Should PHP safe mode be on for starters? Can I limit the exec dir in the php.ini just to /etc/squid/squid_passwd?
Edit: I have added PHP's escapeshellcmd to the code, which strips out characters. I would still like to do the below though with permissions.

Do I:
- create new user scriptsuser
- chown the scripts to that user
- how do I then add permissions for the script to change anything in the /etc/squid/squid_passwd file, which is owned by root?
- in the cron I replace root path/to/scriptname with scriptuser /path/to/scriptname?
- that way any dodgy commands in the database transmission can only be run as scriptuser?

unSpawn · 08-16-2009, 11:01 AM

Quote:

Originally Posted by qwertyjjj

A potential security risk I see with this code is that as the remote mysql server is open to the internet, someone could potentially hack in and enter some stuff into the database fields. Now whilst I can check if someone has entered in their own username/password combo for free access, I don't at present checking the information in the fields. The user and password are passed straight on to the htpasswd command.

The first thing to do IMHO would be to see if you're reinventing the wheel. Check your distro's repo's. Then check Sourceforge, Freshmeat, Nongnu, Berlios and see if something like changepassword doesn't exist yet. Check if the tool uses the interpreter you want to use and if the project is still maintained.

Quote:

Originally Posted by qwertyjjj

What should I be checking for in the fields to see if any dodgy stuff is passed through especially as the script is executed as root at present.

Programming comes with a set of best practices. One of them is to never ever trust user input. On error try not to think for the user and correct things but reject it completely. See these Top 5 Security Tips at the shiflett.org (his web log makes for a good read wrt PHP security so please do), The Problem With PHP Application Security, part #7 of the LQ Security references.

Quote:

Originally Posted by qwertyjjj

Should PHP safe mode be on for starters?

If it's on by default you should aim to understand what it's about, what it affects, if it's a risk itself (0, 1, 2) what the risk of flipping the boolean will be and if there are supported alternatives like suPHP (note) (suPHP being meant for running as other unprivileged users, not root of course).

* I do realise you're between a rock and a hard place with respect to machine delivery time constraints vs configuring and hardening your server and I can only hope the posts I've made in the past days convey to you properly that most information is widely available even with rudimentary search-fu, that knowledge and self-reliance need to be actively cultivated and that, with all due respect, you should choose to think before you act. If that doesn't do it for you think about cost of investment: you can invest to read now resulting in a design for your system that makes it redundant, resilient and reasonably secure or you can cut corners and rush your server into production and then be forced to support it eternally while fixing breakage, dousing fires, patching things up. If that doesn't do it for you think about being a paying customer (if applicable): would you sink money into crappy service with breakage and downtimes going through the roof? Or would you rather trust a solid, smooth-running, hardened server with your business?..