Another answer (and similarly lame), is that if you can't trust your host to properly configure their servers, pick a host that does not allow shell accounts. This will mean more work on your end to debug things (you'll pretty much need your own *NIX box and FTP the site back when you are through), but you won't have any permissions problems.
I would never pay for some account that didn't include a SSH shell, but that's besides this point. Of course you still have permissions problems, since Perl gives you a "shell".
For example the following (horrible) piece of code will give you some nice information. Of course you should regexp on something more useful than just "connect", but this piece of code isn't meant to be too successful ;) And yes, in the loop of found matches, you could open the specific file and/or copy it to your own directory or something ...
#!/usr/bin/perl print "Content-type: text/plain\n\n"; $\ = "\n"; $http_dir = "public_html"; open(PASSWD, "</etc/passwd"); while(<PASSWD>) { chomp; @user = split(":", $_); if($user[2] >= 1000) { print "Found user \"$user[0]\", scanning \"$user[5]/$http_dir\": +"; print "="x70; if(@found = `grep -slr 'connect' $user[5]/$http_dir/*`) { chomp(@found); foreach (@found) { print "Match in: $_"; } } else { print "nothing found..."; } print "\n"; } } close PASSWD;
As far as I can tell, my host is both using suEXEC type behavior *and* is disabling shell accounts. Paranoid? You bet. I like that in a host.
I like the suEXEC bit of your host. The no-shell policy would drive me crazy, but luckily I have my own server(s) :)
Note: I chose to use the backticks for the grep command, because a) it shows you still have a shell when you have FTP access and you're allowed to run CGI apps, and b) it's easier than a native Perl way ;)
In reply to Re: Securing your scripts on webhoster's server
by b10m
in thread Securing your scripts on webhoster's server
by b10m
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |