execute a PHP script as root?

Anon

i have a script which recieves some variables from a form and writes them to a file.

i can create the file OK, but writing anything to the file does not work as the user "web" does not have permission to write to files.

is there anyway to make the script create & write the files as root?

thanks!!!

below is some of my code:

receive the log, write it to a file, parse the XML from the file

    srand ((float) microtime() * 100000000);  # seed the random number generator
    $logname = time()."_".rand().".log";    # create a log name, based on the exact time in seconds
                                            # and a random number 9 digits long


    if (!$fp = fopen("/tmp/".$logname, "w"))  # create the file
    {
            echo "file create failed";
            exit;
    }


    if (!fwrite($fp, $log))  # write the log to the file
    {
            echo "file write failed";
            exit;
    }
    else
    {
            echo "write successful";
            fclose($fp);
    }

i get a "write successful", but the fil eremains empty...

any help appreciated!!! thanks

Anon

Steve,

You just need to set permissions to the work area to web group, or open the directory up chmod 777.

Ron

[deleted]

777? waaaah! forbidden, nono, do not do, never ever ever!

Anon

Yes there is a way, but running a PHP app as root is REALLY, REALLY, REALLY, REALLY, bad unless you know REALLY what you are doing.

Yes vincent is right, setting directory permissions to 777 is bad, but running your application as root is 28,567 times worse.

I personally would go the permissions route.

[deleted]

I'd go the SUDO route and have the best of both worlds; a protected directory and limited higher-privilege access.

Anon

So you propose doing a system call to sudo? Not a very secure idea vincent. That means you will have to have the sudo password either hard-coded in your application or stored somewhere in a database. DB user/pass combos are a cinch to get from PHP apps executing as an unpriviledged user. What you are bassically proposing is possibly giving away root access to the box! Sure beats a world-writable directory.

Anon

How is the script being executed? As a shell-script, or from the web?

Anon

WARNING: simplified explanation.

Steve, the best solution would to be to create a virtualhost on the box and run the application from there. Compile PHP into a binary and execute your applications a cgi under suexec. Your app will then execute as the user specified in your virtualhost tag. This user won't be root, but it won't be an unpriviledged user either. This gives protected directories and protected source (allowing you to hardcode sudo system calls if you wish). Working at a large hosting company with hundreds of servers running PHP applications, I see firsthand the mistakes that many developers make when writing apps. The BIGGEST mistake is the lack understanding as to how WIDE the F OPEN applications are when running as an apache module. If you have one iota of information in your app that you do not want to share with every other user on the box, then running as an apache module is the DUMBEST thing you can do. Any any given moment, I can log onto a box as a normal user and get EVERY db user/pass combo for every php application on that box ( execpt those running as cgi).

Anon

thanks for all your replies.

i have figured out what the problem is... you are going to hate me for this as it is so basic... my "web" user had (without my knowledge) been assigned a tiny quota of webspace which was actually full. therefore it could create the file but not write to it...

agh. thanks for all your help.

[deleted]

"What you are bassically proposing is possibly giving away root access to the box! Sure beats a world-writable directory."

Uhm... do you know what sudo is?

[deleted]

"If you have one iota of information in your app that you do not want to share with every other user on the box, then running as an apache module is the DUMBEST thing you can do. Any any given moment, I can log onto a box as a normal user and get EVERY db user/pass combo for every php application on that box ( execpt those running as cgi)."

That's if you have your servers setup to run one apache for many different clients, which is indeed a DUMBEST thing you can do.

A sane person would setup a different apache environment for every client. Then every client's webserver runs as a different user and nobody can read eachothers sourcecodes anymore, not even through PHP calls.

BTW, I am very curious what kind of hosting company you work for if you can just logon and read everybody's files without being root.

Anon

Dude, you have no idea. Typically, we set-up about 250 sites on a shared server. So, you mean to have 250 separate apache daemons????? 250 separate root apache daemons that fork off children processes. So if you set minstartservers to 5, then you have 1500 separate apache processes at any one time. Do you realize how much your server load would be? Do you realize that no one would be able to send mail through your server, because sendmail starts queueing mail after a servers load goes above 5?
That means 250 separate httpd.conf files???? What if you wanted to make a global change to apache's configuration. Instead of making one change to one conf, you would have to make one change to 250 conf files. Thats a brillant idea vincent! What do you think <virtualhost> tags are for? Exactly how many shared (100+ sites) boxes have you ever administered?

And yes, I do know what sudo is. It allows you to execute commands as a different user.
Only users who are in the sudoers file can sudo. Sudo also prompts for a password unless you use the -S switch, which then reads fom STDIN. Since you can't call sudo via a script and not use the -S switch, steve r would have to HARD-CODE his password into his application. He would be HARD-CODING a password that allowed commands to be executed as root. That is just as bad as HARD-CODING roots password into your app.

By the way, I work at a respected hosting company who deals with the occasional idiot, such as yourself, everyday.

[deleted]

"Typically, we set-up about 250 sites on a shared server"

and you take yourself seriously?

"So, you mean to have 250 separate apache daemons?"

(one questionmark is enough thanks)
Why not, if you have enough CPU and memory.

"So if you set minstartservers to 5, then you have 1500 separate apache processes at any one time. Do you realize how much your server load would be?"

Yup, just as high as your load is now, just with more memory in use.

"Do you realize that no one would be able to send mail through your server, because sendmail starts queueing mail after a servers load goes above 5?"

If you think that idle processes bring your CPU to a load of 5 maybe.

"Thats a brillant idea vincent!"

indeed it is.
I suppose in your company you still maintain all the files by hand?

"What do you think <virtualhost> tags are for?"

For those who don't care about security, performance and reliability.

"Exactly how many shared (100+ sites) boxes have you ever administered?"

We had around 100 co-located servers, 245 dedicated servers and just over 400 shared servers, but being an intelligent crew we never allowed more than 25 shared customers per server, at which point you still have good performance for each client. Performance, ever heard of it? I guess not at 250 users per server.

"Since you can't call sudo via a script"

why not, I do it all the time, that's what sudo is for.

"and not use the -S switch, steve r would have to HARD-CODE his password into his application"

... on the other hand he could also just store the password in an apache environment var for that particular (virtual) server, in which case only the sysadmin can read it, but he is root anyway.

And who cares about that anyway? how does it help you to know the sudo password for one particular script that does something in someone-else's directory? You still can't execute it because it's not in your directory.

"By the way, I work at a respected hosting company who deals with the occasional idiot, such as yourself, everyday."

It's good to know that you can always fallback to calling people an idiot isn't it?

Judging from your posts so far I'd say it suits your IQ pretty well.

Anon

I checked out what you provide.

So a max of 25 clients on a shared box. Charging (for the advanced website) 35 eur or $30 is a recurring monthly revenue of $750 dollars per server. Given the mix-and-match of account types, you are talking about probably $1250 a month in recurring monthly reveue per-server. Considering the money spent on paying your upstream provider for bandwidth, hours spent on maintaining a box, man-power to provide technical support to clients and renting office space, how do you make money off of $1250 monthly recurring revenue per server? I understand that there are additional charges to be incurred (bandwidth overage, disk use overage, consultation), but these aren't guaranteed sources of income. Plus with your model, you would have to build a mac daddy box to only make $1250 a month.
Who really suffers is your client base. You aren't able to provide a wide-variety of services to your basic level customers (I checked out your site). What you provide at $19 a month is about 1/3 what we provide. Why? Because we are utilizing our resources better. Thats why we have 250 clients on a box. Our business $22.95 package is comparable to your $87 professional package. In fact we offer a reseller package that allows resellers to add sites for $2 a month! A $2 site that is comparable to your $87 a month package. With a client base of 100,000+ virtual sites (with over 250 being added each week), I would say that people are pretty satisfied. But yes, there are downsides to our model, namely (the one that spawned this flame trade) is unprotected php code. But with proper precautions (running as cgi), this can be circumvented.

I quit... I have work to do.

[deleted]

"I checked out what you provide."

Uhm.. no, you checked out the hosting company that suppies me with the email adress I use to post on PHPbuilder.

The hosting company that I worked for was geared towards 'professional' clients who paid well over $300 a month for a shared account. and double that for a dedicated server.

25x300=7500 a month per server. Plus if you are as big as they were, the bandwidth is dead-cheap. man hours; well most of it was automated like I said. All we did was install new servers and plug them into the management network from there everything was auto, from adding new customers to reconfiguring the servers.

I quit too, flaming is fun for about 4 mails, after that it becomes a "did too, did not, did too" kind of thing.

Besides which this forum is about PHP and not hosting :-)

Host lots and prosper.

Anon

hi i just want to say that if your prob is about chmod 777. you can email me in person so that i can help you ..... in exact manner....

do keep up the good work...

you can visit me
http://www.wsmen.8m.com

[deleted]

Uhm... chmod 777 is NEVER the solution.

Anon

There is one thing that I don't understand and would like to know how to do. How do you bind multiple apache daemons to port 80?

[deleted]

If you're talking about seperate deamons, truely seperate processes, then 'all' you have to do is make sure that they all have port 80 configured, and that they all have a different IP to listen to.

It's the combination of IP and port that must be unique to every apache server.
If the ports are the same then the IP must be different, and if the IP is the same then the ports must be different.

...and now you're going to tell me you use name-based virtual hosting right? :-)

Anon

Not anymore. Everyone now gets their own IP. At one time we used shared IPs, and a client would get their own IP for one of three reasons.

Client wanted to set-up anonymous FTP
Client wanted their own certificate
Client bought the IP