Mod_wsgi with dynamically allocated UIDs

No, WSGIAccessScript is not for user authorisation, it is purely for host based access control independent of whether a user has been authenticated or authorised. User authorisation is handled using WSGIAuthGroupScript directive. See:

http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms#Apache_Group_Authorisation

The error your saw can also occur as a transient issue if you have done an Apache graceful restart and an Apache worker process had socket connections still alive that hadn't yet called through to mod_wsgi daemon process for initial request or subsequent request due to keep alive on socket.

This will occur because on graceful restart the mod_wsgi daemon process are restarted regardless and in doing that, the path to the socket file is change so different. This means that old worker processes hanging around to handle current and keepalive requests will fail to connect to daemon as they will still be trying to use old path for socket file.

As to the directory where socket files are, the important thing is that the directory is readable to www-data. The sockets will be created as root initially with perms 0600 and then ownership should be changed to www-data so www-data worker processes can connect and nothing else. This is dependent on directory still being accessible to www-data.

The reason for WSGISocketPrefix is that Redhat made the logs directory where Apache config says to put this stuff as default, to not be readable to others so www-data couldn't see sockets in directory. This is why on Redhat one needs to change it to /var/run.

At what point the directory permissions get changed or fixed and whether than can happen without Apache package upgrade, don't know.