A hacking incident a couple of months ago taught me the importance of using open_basedir on PHP sites. But now I need to get ImageMagick to work on a Drupal site and I get an error saying it can't access /usr/bin/convert because of open_basedir. /usr/bin and everything in it is writable only by root, but there are a lot of scripts in there, and giving the site access to all of them worries me.
No, it isn't safe to add /usr/bin to open_basedir. Once an attacker can execute arbitrary PHP code they will then be able to execute any command in /usr/bin.
To limit the attack surface area you could create a bin directory under open_basedir and make a link to convert in it. Make sure it isn't under your web root.
Obviously we don't know the details of the hack, but in order to exploit something which might have been prevented by setting open_basedir properly then there is a different vulnerability on your system. But that's beside the point.
There are lots of ways to solve the problem - allowing the PHP script limited access to the relevant binaries / setting up the permissions so you can allow access to the dir without exposing lots of other stuff (but unless your imagemagick is statically linked then you'll also need to open up the libs). The problem is that they rely on Byzantine permission models - which are likely to get trampled on by distro upgrades.
If it were me I'd run the conversion in a completely independent process group. How you go about that depends on whether your PHP script needs to know if the job completes successfully or not. If it doesn't need to know, then an asynchrnous message queue (rabbitMQ, SMTP linked to a procmail recipe, or just some records in a database) will process the jobs with manageable capacity. If it needs a confirmation, then run a forking daemon to exec the conversion.