Hi,
I am in the process of designing a program which performs a form of
task scheduling. Briefly, the system will execute tasks based on
system events (I'm thinking dial-up networking, here) rather than at a
given time (as cron does).
However, I have come up with a problem about the best (most secure)
way of managing user permissions for this program. Basically, what
I'm after is something which behaves rather like crontab: There is a
"system" repository of tasks (like /etc/crontab), and "per-user" tasks
(like /var/spool/cron/<user>, or whatever).
The "per-user" tasks are executed (under the users own identity)
when the scheduler is triggered. These tasks are placed in an
otherwise write-protected area by a suid program, in a similar manner
to crontab.
This is fine, and (I think) I could do this without too much
difficulty. However, there is one additional twist: there are two
types of task -- transient and permanent. The transient tasks are
executed once (on the next trigger event) and then deleted; the
permanent tasks are executed at every trigger event. I think that
there should be a directory structure looking something like this:
/var/spool/taskscheduler/
permanent/
user1/<files...>
user2/<files...>
...
transient/
user1/<files...>
...
What I'd like is to have a nested set of permissions:
Set (A): Some subset of all users -- able to set transient events
Set (B): Some subset of (A) -- able to set permanent events
I can see a couple of ways of achieving this:
1) Have two groups (say, tsperm and tstemp) which grant access to the
appropriate configuration directory (the dirs are root.ts(perm|temp)
drwxrwx--t). -- This allows the user to edit directly their
configuration files.
2) Have two groups granting access, and check users' membership of the
appropriate group before allowing them access to the spool dirs (which
are root.root drwx------). -- This requires a suid-root program.
3) Have two lists of users in a configuration file, allowing access to
the spool dirs (root.root drwx------ as above). -- This also requires
a suid-root program.
I *think* that option 2 is the one to go for, but I'm not sure.
So... my questions are:
Which of the above options is the best in terms of secure design?
Are there any other sensible options I've missed?
What pitfalls should I try to avoid in implementing this design?
I'd appreciate comments on this. Thanks,
Hugo.
--
---- Hugo Mills --- The Creature from the Black Logon ----
hugoat_private hugoat_private hugoat_private
---- "We did a risk management review. We concluded ----
that there was no risk of any management."
This archive was generated by hypermail 2b30 : Fri May 25 2001 - 11:04:13 PDT