>Why not just setup something which is in some way connected to the existing
>file access groups? (You know, the stuff in /etc/group.)
There could be some scope for this. However a number of important design
questions have to be answered:
Do we use additional groups or just the GID of the process?
If we use additional groups do we use the most restrictive or the least
restrictive to set the policy? If we use additional groups then things could
become confusing when a user can start a process in one context but not in
another.
The option of "just setup something in /etc/groups" does not solve the
problem. If we base it on /etc/groups then we have to decide how to do so in
addition to the other issues I've already considered (how to tell the kernel to
start doing this and how many processes per group - probably through something
in /proc).
I think that the best option is to have a security descriptor for each
process as used in VMS (and advocated in a message I received a short time ago
but accidentally deleted so I can't quote it). However I don't have the
knowledge required to code this and I am too busy to learn at the moment. If
someone has some suggestions for filing system security then I would be very
interested as my main Linux programming project is the design of a new filing
system... But if the number of processes limiting code is to be developed by
me then it'll be a few dozen lines of code based on catting a few values to
file(s) in /etc/proc (but don't let me discourage you from implementing it your
way if you've got the time and desire).
Russell Coker