Although it is possible to specify the socket by using mysqldump’s --socket switch, that doesn’t really seem a ‘solution’.

Apparently mysqldump, as opposed to the mysql client does not use the server-specific settings contained in /usr/local/zend/mysql/data/my.cnf. The comments in my.cnf state:

# You can copy this file to
# /etc/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is /usr/local/zend/mysql/data) or
# ~/.my.cnf to set user-specific options.

After copying /usr/local/zend/mysql/data/my.cnf to /etc/my.cnf mysqldump worked as expected.

In /etc/my.cnf I have included only the setting needed to get mysqldump running:

# Specifying socket to use for mysql/mysqldump
# For other settings refer to /usr/local/zend/mysql/data/my.cnf
[client]
socket      = /usr/local/zend/mysql/tmp/mysql.sock

Hope this saves anyone running into the same issue some time.

Update (alternative solutions):
As Joel Clermont pointed out it is also possible to create a symlink on the socket location expected by mysqldump to the real socket location. This can be done by executing:

ln -s /usr/local/zend/mysql/tmp/mysql.sock /tmp/mysql.sock


Another possible approach is to create a symlink at /etc/my.cnf to /usr/local/zend/mysql/data/my.cnf. This has the downside that it requires loosening the default permissions (drwxr-x---) on the data folder by allowing ‘others’ to enter it. Commands to execute:

sudo chmod o+x /usr/local/zend/mysql/data
sudo ln -s /usr/local/zend/mysql/data/my.cnf my.cnf

Granting more permissions can be a security consideration but on most development setups this probably won’t be an issue.

Additional info about Zend Server CE on OS X:

• Zend Server CE Documentation
• Rob Allen: Some notes on Zend Server CE for Mac OS X

• Prepared statements. There’s no need to concat potentially harmful data in SQL statements. Provide them as a parameter when executung a prepared statement. More efficient too.
• ORM. If you think SQL should be behind an abstraction layer, you can do so. Propel and Doctrine are the best known solutions for PHP.
• Well structured programming. If, for some reason, you want to build queries the old way you can force upon yourself (or your team) some good practices. See example below.

$dataTainted['un'] = $_POST['un'];
$dataTainted['pw'] = $_POST['pw'];
 
// escape all array values using a custom function of some sort
$dataSafe = mysqlEscapeValues($dataTainted);
 
$query = <<<SQL
SELECT
  *
FROM
  users
WHERE
  un = "{$dataSafe['un']}"
AND
  pw = SHA1("{$dataSafe['pw']}")
SQL;

And that’s just the coding part of the story. In the area of application design a lot can be done to minimize the consequences of an exploit. For example, different database users can be set up that have different levels of access. Only parts of a website needing customer data then use the credentials that do provide such access.

So, for PHP there are good practices and solutions aplenty. For more information on SQL injection one can start at OWASP or Wikipedia. And finally, the subject isn’t non-existent in .NET and JSP.