It would probably be better to add this feature to cron.
In fact I'm not sure that you even need to distinguish "system" from "user" for
cron - even system cron jobs will probably have small memory footprints and
small numbers of children so you could just set limits in the rc script which
starts cron - eg change the line which starts cron so that it reads something
like
/bin/bash -c "ulimit -u 10; exec crond"
that will run a shell (so the limits only apply to the cron daemon), set the
max no of user processes and then start cron with that limit. As long as "the
right thing" happens as cron switches UIDs (i.e cron ends up being limited to
10 processes per UID and not 10 total in the above example)
This seems to be a prime example of a case where the kernel already provides
the mechanism adequately and it's up to the system administrator to define a
policy which uses it - should he believe that he has a user community which
requires these sorts of limits to be set.
Regards
Paul.