Crond has a number of built in limitations to reduce the chance of it being ill-used. Potentially infinite loops during parsing are dealt with via a failsafe counter, and user crontabs are generally limited to 256 crontab entries. crontab lines may not be longer than 1024 characters, including the newline.
Whenever crond must run a job, it first creates a daemon-owned temporary file O_EXCL and O_APPEND to store any output, then fork()s and changes its user and group permissions to match that of the user the job is being run for, then exec's /bin/sh -c to run the job. The temporary file remains under the ownership of the daemon to prevent the user from tampering with it. Upon job completion, crond verifies the secureness of the mail file and, if it has been appended to, mails to the file to user. The sendmail program is run under the user's uid to prevent mail related security holes. Unlike crontab , the crond program does not leave an open descriptor to the file for the duration of the job's execution as this might cause crond to run out of descriptors. When crontab program allows a user to edit his crontab, it copies the crontab to a user owned file before running the user's prefered editor. The suid crontab programs keeps an open descriptor to the file which it later uses to copy the file back, thereby ensuring the user has not tampered with the file type.
Crond always synchronizes to the top of the minute, checking the current time against the list of possible jobs. The list is stored such that the scan goes very quickly, and crond can deal with several thousand entries without taking any noticable amount of cpu.