If you have a look at the main Apache2 config file, /etc/apache2/httpd.conf you will see that there are two things that have to be done to allow /Library/WebServer/CGI-Executables contain the cgi files.
First, since it isn't covered by the permissions for the document directory next to it, it will need a "Directory" block to define the permissions for all the files and directories under it. In the case of this directory it allows absolutely nothing to happen. This is why when you pointed your browser at the directory it said permissions denied. Don't worry, the second thing allows cgi files in the directory to be run.
Second, it needs a "ScriptAlias" command that tells the server what URL will be used to point to it so that the server finds the files and allows them to be run.
ScriptAliasMatch ^/cgi-bin/((?!(?i:webobjects)).*$) \
"/Library/WebServer/CGI-Executables/$1"
This basically says "after you remove the hostname then any URL that starts "/cgi-bin/" and continues with a piece of text followed by a period followed by another piece of text points to a file with a name matching the last bit in the directory ""/Library/WebServer/CGI-Executables/$1"
If you want to place CGI files in one of your user directories then you will need to make some changes to a different config file. You will find the config file for user shares in /etc/apache2/users with a config file for each user. Here is an example:
<Directory "/Users/jessica/Sites/">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
To this you will have to add either "ExecCGI" to the "Options" line so that you can have CGI files anywhere in your Sites directory or under or add a new Directory block for your CGI folder. It would look like this :-
<Directory "/Users/jessica/Sites/CGI">
Options ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Since this is under our DocumentRoot we don't need to use the ScriptAliasMatch.
(The second option is the more secure.)
Best Answer
The nobody user is non-interactive and doesn’t have calendars anyways. You will need to have some component (maybe another custom app/process) running as you to deliver the calendar info.
You really have two options, one of which is very bad.
Firstly, you could have your CGI scripts run as you. This isn’t hard but super dangerous and not recommended.
Secondly, you can build what is essentially a calendar proxy. This could be another program (running as you) which ever five minutes reads the calendar data and writes it out to a file which nobody, the account, can read. You already seem to be familiar and working just fine with calendars so this shouldn’t be an issue, it’s just another script that you schedule with cron.
Another thing, though I’m really not sure if it will work for nobody, is that you can run
sudo su nobodyand then launch it. Since OSX knows that the PTTY is attached to your user session it will show the prompt there for you to accept. While you still won’t be able to access your users calendars, this trick is useful if you have to use these sorts of permissions as root whom also doesn’t a graphical session.