On Thu, August 18, 2005 12:22 am, Roger Thomas wrote:
> Quoting Richard Lynch <ceo@xxxxxxxxx>:
>
>> If 'www' can do it in a shell, then PHP, running as 'www' can
>> usually do do it
>
> www is a Limux system user on both svrA and svrB.
> On svrA, Apache runs as user nobody. I mean, this is the httpd user,
> where we defined it in httpd.conf:
> User nobody
> Group nobody
>
> My bad, I shud have use roger instead of www.
Is 'www' a "real" user on either server?
What is that user allowed to do?
Does that user exist for the express purpose of doing "things" related
to the web-server, and nothing else?
If so, the easiest solution might be to change httpd.conf to have:
User www
It gives Apache/PHP a little more power ; which increases risk a bit
But if 'www' ONLY has permissions to do the kinds of things you want
to allow Apache/PHP to do, then that's okay.
If 'www' has lots and lots of permisions to do all sorts of things,
then it is a Bad Idea to do httpd.conf: User www
>> This will tell you what error messages, if any, you are getting.
Damn!
Error 255 is not particularly enlightening, at least to me -- But I
think it indicates a problem before PHP even manages to FIND the "ssh"
command, not one actually trying to run it.
Somebody who knows OS error codes better than me could maybe clarify
this a bit.
>> Most likely what is happening is that the 'www' user in PHP does not
>> have a true shell set up -- so 'www' has no "home" dir, so ssh does
>> not find the keys you stuck in ~/.ssh/ so you need to do something
>> like:
>>
>> exec('ssh -i /home/www/.ssh www@svrB /tmp/test.sh someDIR', $output,
>> $error);
>
> In my case, user nobody (that Apache runs as in svrA), does not have a
> true shell setup. How do I create a private/public key for user nobody
> when I can't even login as user nobody (as it does not have a true
> shell) ?
You *might* be able to use the "-i /home/www/.ssh" part, so long as
the "nobody" user can *READ* www's key files...
Though that may not be desirable.
In detail, you *COULD* create a group called 'www_nobody' and add both
'www' and 'nobody' to it, and then you *COULD* chgrp 'www_nobody'
/home/www/.ssh/ (and/or some files within that) and THEN I think the
exec() would work with the "-i /home/www/.ssh" because now "nobody" is
using "www"s keyring to get into whatever "www" can get into.
Though, at that point, maybe just changing httpd.conf to User www is
looking more attractive.
You should first try something more simple like:
exec("ls", $output, $error);
if ($error) echo "OS Error: $error\n";
echo implode("\n", $output);
just to be certain the "nobody" user can do *anything* with exec()
It *MAY* be a requirement that "nobody" has some kind of shell access
for exec() to work... I don't know for sure about that.
But this quick test without the vagaries of ssh and keys and
permissions involved will sort of work towards your goal from the
other end -- getting PHP to execute *something* in the shell, and
knowing that that something is so damn simple that it HAS to work. :-)
If the Apacher user *HAS* to have a valid shell to use exec() then
you're kinda stuck with User www, or some other user like 'www-run'
which I sometimes see... Possibly because for the same reasons that
you have a 'www' user already and don't want to use that for
httpd.conf User.
You may also want to use things like /usr/bin/ls and
/usr/local/bin/ssh or whatever they are on your box. Better to use a
full path and be sure you are not subject to the whims of the shell
and some $PATH environment variable that root might change out from
under you some day by messing with /etc/passwd in a security audit.
> What's my option ?
Short version:
Make sure PHP can do something useful with exec() like "ls"
Make sure PHP can *read* the keys it needs to get into srvB
Use full path to "ssh" and use "-i /home/www/.ssh" so PHP knows it's
supposed to get the keys from there.
>> Though why you have a 'www@svrA' user and then have 'nobody@svrA'
>> running Apache/PHP is beyond my ken...
>
> Sorry for the confusion.
'Sokay.
Just wondering WHY you have a user named 'www' if it's NOT to run
Apache...
It's pretty common to have a user 'www' (or similar) running Apache
just so you can keep the web stuff out of the hands of "nobody" (IE,
everybody) and have a username everybody recognizes as "the user that
runs Apache"
But then I've seen those boxes where it's 'www-run' or 'apache' or
other more interesting usernames running Apache/PHP, so it's not
really written in stone.
>> It's usually the PRIVATE key belonging to 'www@svrA' that you would
>> have sitting in the .ssh directory for 'www@svrA' and then the
>> PUBLIC
>> half would be sitting in 'www@svrB' .ssh directory.
>
> Yes, I did that. I logged in as user www in svrA and executed
> ssh-keygen -t rsa. I then copied id_rsa.pub to svrB and called it
> /home/www/.ssh/authorized_keys. As noted, user www are system users in
> svrA and svrB.
>
>> I'd be real worried about the script that only 'root' can run...
>>
>> Set up a new user on svrB that has permission to create the
>> directories you need, and that's pretty much all that user can do.
>>
>> Using 'root' access is just too much power.
>
> I mean, I want to execute a command in svrB where only root can do so.
> Like 'shutdown' or something else.
Yikes.
How hard will it be for a Bad Guy to hit the page on srvA and shutdown
srvB? Cuz if it's not REALLY REALLY REALLY hard for a Bad Guy to do
that, you should *NOT* do this.
To limit the scope of problems, have root write the script on srvA and
make it executable ONLY by 'www@srvA'
You can do that by putting 'root@srvA' and 'www@srvA' in a new group
'www_root@srvA'
You then chmod the script to run as the owner of the script rather
than as the user running the script.
Finally, chgrp the script to 'www_root' and chmod it to be group
executable.
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
