cronjob / wget error

Portal Home > Knowledgebase > Articles Database > cronjob / wget error

Posted by Calibaba, 04-11-2008, 05:12 PM
Cronjob is not working for a script on a clients cpanel account: He set it up to grab from the path below and it is giving this error: /bin/sh: /usr/bin/wget: Permission denied The cronjob that is running is: /usr/bin/wget -O - -q http://domain.com/cron.php This is a cpanel box with centos 5
Posted by JulesR, 04-11-2008, 05:14 PM
The user the cronjob is executing as doesn't have permission to access the wget binary. Either move the cronjob to a different account that does have permission (ie 'root'), or allow that user permission accordingly.
Posted by mnu, 04-11-2008, 05:15 PM
Is this only occurring with wget? What do the perms/ownership look like on wget? stat /usr/bin/wget
Posted by Calibaba, 04-11-2008, 05:20 PM
This is a *shared* cpanel client, I cannot relate "root" with his account in any way. Too risky.
Posted by JulesR, 04-11-2008, 05:21 PM
Then allow the user permission to access wget For the record, if the domain is held locally, they don't necessarily need to 'wget' the file. They could just run the script straight off with the PHP binary instead.
Posted by Calibaba, 04-11-2008, 05:21 PM
Isn't that risky? Anyway, how is that done? Never did that before
Posted by Calibaba, 04-11-2008, 05:25 PM
You mean like this?? /usr/bin/php -O - -q /path/to/domain/files/cron.php
Posted by JulesR, 04-11-2008, 05:26 PM
As with any permissions change, it's potentially risky, yep. I guess it comes down to how strict and secure you want to be. Your best bet would be to get the client to run the script directly using PHP instead of hitting the page. The end result should be exactly the same as their wget request with the exception of their being no saved output. Why is the output necessary anyway? If they need output, then it'd be fairly trivial for any PHP developer to modify the script to create output accordingly without using wget.
Posted by whmcsguru, 04-11-2008, 05:27 PM
Is wget risky? Is ANYTHING risky? C'mon now. Proper administration here. Wget is risky, allowing hosting clients is risky, guess you should pack up now, running a server is risky, guess you need to just find another line of business. Wget is fine, disabling things because you don't know how to properly admin a server is wrong. In that case, you might just as well disable php, perl, etc. How to enable wget? From inside the shell
Posted by JulesR, 04-11-2008, 05:28 PM
No, I meant it exactly as I posted earlier: Obviously substitute the path to cron.php so that it's correct. The "-O" flag on the wget command outputs the result of wget to a file. The "-q" flag enables quiet mode, with no output of the wget process at all. These flags aren't used when calling PHP directly in this instance, so aren't needed.
Posted by JulesR, 04-11-2008, 05:35 PM
wget on its own is fine. wget, however, used in conjunction with a badly developed PHP script to download a remote shell script is NOT fine. See the difference here? How do you propose to protect against that? mod_security? Oh please. Ignore his comments, Calibaba.
Posted by Calibaba, 04-11-2008, 05:37 PM
I didn't bother paying attention to his comments JulesR. The guy is being a prick, meanwhile he promotes his "security/administration" business right in his own signature. Go figure. I knew there was a good risk in allowing wget for shared clients, that is why I did not intend on doing so. I asked first as a clarification. Thanks for your help Jules.
Posted by whmcsguru, 04-11-2008, 05:49 PM
Calibaba I was not being a 'prick', nor was I recommending my own services. You may not like the answer given, but you know what? it works. In the time I've done business, I've had minimal attacks against things on my servers, and those I admin , and those that WERE started up didn't last long. Why? Because I know what's going on with my servers. Rather than just 'disable everything' , I find it better to take an approach that doesn't limit customer usage to minimalistic approaches. There are many approaches to 'security'. One is to just ignore the customer's needs and chmod everything sso they can't touch it, but in that case you're not going to get anywhere One is to limit particular applications, or force them to run under particular environments (ie: phpsuexec) which won't get them anywhere either. The other is to actually understand and read what your server is telling you. If something goes wrong, then you know about it easily and quickly enough and respond to it. This, I've found is the BEST approach, because it reduces the tickets saying "I can't use this application", maintains client retention, and has a very minimalistic interference with things. That's not saying that my way is the ONLY way to do things, but attacking my way doesn't prove productive at all. I may have (jokingly) said something about how you do things, but that wasn't meant as being a prick, or being anywhere offensive. You asked how to fix wget so it's useful, you have the answer. Wget is, in fact, VERY useful in a shared environment, and there ARE alternatives to mod_security to block bad scripts from using it. Last edited by whmcsguru; 04-11-2008 at 05:49 PM. Reason: Misspelled name, sorry
Posted by scamp81, 04-12-2008, 08:42 PM
you can always use sudo to allow him access to that specific command and only that command. youruser ALL = NOPASSWD: /usr/bin/wget -O - -q http://domain.com/cron.php
Posted by Panopta, 04-12-2008, 09:19 PM
You really don't want to do this if you don't completely trust your users - this will actually run wget as root, with full root permissions. This opens the door to potential compromise if there are any security problems in wget. It's much safer to just grant wider execute privileges for /usr/bin/wget so it still executes as the customer's restricted user. For many setups, this is a rather moot argument anyway as the customer could just upload their own wget executable and setup their cronjob to use that instead.
Posted by spal911, 04-13-2008, 01:10 AM
You can also use curl if wget is disabled curl -O
Posted by ub3r, 04-13-2008, 08:04 AM
Do you have ssh access? You could compile wget in your homedirectory like so: ./configure --prefix=/home/yourusername/wget make make install then wget would be installed under /home/yourusername/wget/bin/wget and you could set whatever permissions you'd like on that binary, and configure your crontab to use it.
Posted by whmcsguru, 04-13-2008, 01:14 PM
It's really not realistic to deny access to system things such as this, as suggested here. People can compile, even re-upload the binary. As well, allowing someone sudo access just for wget seems quite a bit drastic to me.
Posted by brianoz, 04-14-2008, 03:25 AM
If you want to prevent most people from using wget, just provide a renamed copy somewhere that allows execution. For instance, "wget.ok". You need to make sure that they can't easily find it by removing read permission from the directory it's in (not hard but be careful!). Just some random thoughts - Security is about layers; mod_security plus no wget permissions is fairly secure IMO. Sudo for wget would be insane, don't go there. linux-tech may be many things but he's an experienced admin with good ideas. (not that I always agree, but that doesn't mean the ideas are invalid). I don't subscribe to the philosophy that everything should be tied down in a hosting environment as you end up with a system that's pretty unusable.
Posted by JulesR, 04-14-2008, 05:16 AM
Yet you promote the use of mod_security which, using default rules, is a complete nightmare?
Posted by brianoz, 04-14-2008, 06:21 AM
mod_security is a godsend, not a nightmare - although perhaps I've never used the default rules. Properly configured, mod_security is a real help and no-one should do without it. Except Jules.
Posted by JulesR, 04-14-2008, 06:25 AM
Properly configured" being the key words here On shared hosting that can take a very, very, very long time to get "just right", depending on your clients requirements. Still never a substitute for secure coding practices

Add to Favourites Print this Article