Set the directory's options then don't let the user override them.

For multiuser systems, if you don't trust the individual users for whatever reason, but they might need CGI access, I prefer using CGIWrap (or for Apache, suEXEC).

As the CGIs are then run as the individual web user, and not the httpd user, you can use standard unix groups to control who has access to execute perl. (well, that assumes they don't just drop a new copy of perl on the system, as they must have write support, or you wouldn't be asking the question).

Another option would be to include a perl binary in thier home directroy, and have it so that they can't run perls from other users. This would also mean that the users can upgrade their own perl versions (if you leave the permissions open enough).

Or you could go even further and trap the user in a chroot and stick a perl in there. (Ensim do whole bundlels of this)

Given that the OP talked about Apache, then that's a Really Bad Idea, as it would let remote users construct requests like http://example.com/~user/perl%20-e%20'system("rm%20-rf")'.

Another option would be to include a perl binary in thier home directroy ...

Home directory ne document root

It would be a terrible idea to expose a user's home directory as their document root, this is why apache defaults to sharing ~user/public_html/ as ~user/ to the world

The user would still have to stick perl in a ScriptAlias'ed or Options +ExecCGI'ed directory for your url to have a chance of working, Apache would try to find a file called q[perl -e 'system("rm -rf")'], which won't generally be there. In an html directory, they'd be likely to get a download of the perl binary instead.

@_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;

Update

• added the bit about a file called q[ perl -e 'system("rm -rf")']