[bug-gcron] design.texi

[Ryan M. Golbeck]

This is a messaged I wrote about the the possible designs on the crond
we can take while cooresponding with someone.  I'm posting it up here
so that its recorded in the archives and can be commented on so that a
design.texi document can be written up.

------- Start of forwarded message -------
Envelope-to: address@hidden
Delivery-date: Sun, 17 Nov 2002 15:48:10 -0500
From: address@hidden (Ryan M. Golbeck)

Subject: Re: gcron
Sender: "Ryan M. Golbeck" <address@hidden>
Date: Sun, 17 Nov 2002 15:48:10 -0500


> Did you already produce any documents like a specification or
> documentation?  What is your general strategy for the project?

I started to produce a specification before I started, and have been
continuing it after I started the code.  It (and the beginnings of a
user manual), are in the docs/ subdirectory of the project.

You should be able to get the project from CVS by looking at the
savannah project page.  

As for my strategy, I was writing some core functionality for libcron
and then started to write the crontab.  I wanted to hold off on
writing the actual daemon until I was sure of the design of it.

I have several ideas for the design of the actual daemon, which will
affect libcron slightly as well.


1) crond uses sockets to communicate with user requests for changing
crontab information.  This likely means that crond will have two
threads, one for worrying about executing jobs and the other for
listening on a unix socket for requests.  So the 'talk' protocol for
requesting information and such, to the daemon would just be
implemented in libcron and the user wouldn't know that they are using
sockets at all.

The advantages to this approach is that there are no more suid
binaries (this is a must), all input can be checked on the way in and
written to disk or wherever by the trusted daemon (rather than the
user, currently), and it also allows more complex communication to
happen.  If the user wants to know about status information, running
times, etc, it can be asked of the daemon.

Disadvantages are things like DoSing the cron daemon because anything
can write to the socket.  It is also a tricky setup to authenticate
properly over the socket. (Note that syslog does it this way)

2) The normal way, except without setuid bits.  this mean installing
crontabs into homedirs or into world writable directories.  Both
have major disadvantages and so I would prefer solution 1.  

Do you have any ideas or thoughts about these?

ryan
------- End of forwarded message -------