CalendarScript - Calendar Documentation: Security

Changing File Locations

By default, your 'calendarscript' directory will exist in the same place as the actual CGI perl script files, usually in the cgi-bin folder. There are two cases where this will not work well, however:

If no files or directories under the cgi-bin directory can be set with CHMOD 777.
If your web server is mis-configured, and a web browser can browse through the contents of the 'calendarscript' directory.

Most web servers will not allow people to browse the contents of anything under the cgi-bin directory. If a server is not configured properly, however, a user might be able to load the /cgi-bin/calendarscript/ directory in the browser and look at the contents. This would include the config files, events files, and schedules for all events. If you have calendars which are password-protected or events which are private, or if you are just security-conscious, this is not acceptable.

In these situations, it is recommended that you move the 'calendarscript' directory to another file location, preferrably outside of the document root of the web server.

Doing this will cause the script to longer be able to find the files anymore, however, so you must then go in and edit the $BASE_DIR line in the two Perl scripts to point to the new location of the files. For instructions on how to do this, see the Troubleshooting Installation section.

Encrypted passwords

Passwords for users are stored in the users.txt file, in encrypted form. This means that even if someone is able to view the file, they will still not be able to view the actual passwords.

Some systems, however, do not support Perl's crypt() command which encrypts the password. If this is the case, then the program will either fail or the passwords themselves will not be encrypted.

File locking

Since the calendar is a multi-user environment, meaning different people may be editing configuration entries or adding events the same time, file locking is required. This prevents two processes of the script from colliding with each other when reading/writing data to/from files at the same time.

Some systems, however, to not correctly implement Perl's flock() call to lock files. If this is the case, then the application will continue to function as normal, but files will not be locked and corruption of data is possible. For this reason, do not use operating systems such as Windows 95 to serve this program.