Thanks for your great explaination. I really appreciate that. I will try out the things that you have outlined and will be back if I land into trouble :)
--
Roger
Quoting Richard Lynch <ceo@xxxxxxxxx>:
> 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
>
>
>
---------------------------------------------------
Sign Up for free Email at http://ureg.home.net.my/
---------------------------------------------------
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
