Messages in this thread |  | | Date | Thu, 26 Dec 1996 09:49:22 +0200 | From | Andi Gutmans <> | Subject | Re: NT vulnerable to attack on CPU |
| |
Hi,
I think the way you think to implement it is far superior that what I thought of. My knowledge of the kernel isn't good enough to do it with /proc so maybe I'll wait until you get around to it. I don't think you need to seperate staff. On my machine for example staff is uid's <1000 so what should be done is to echo "1000" > /proc/blah and maybe echo "64" > /proc/blah_proccessesallowed You can always hard & soft limit proccesses for staff later on with regular limits. SO there are ways with crontab etc.. to get around them but I don't expect most of my staff to try and bomb the system. If they will they won't be staff anymore.
Andi
At 14:00 26/12/96 +1000, bofh@snoopy.virtual.net.au wrote: >>put a cronjob to run a bomb and this won't have any effect. >>ie. linux limits (and prolly most unicees) are useless. >>I'm prolly going to hack the kernel a bit to do the following: >>certain limit for uid's < 1000 >>and certain limit for uid's > 1000 (users) > > I've been thinking of doing a similar hack. However what I would do is put >some files under /proc/sys to specify the UID number that differentiates system >processes from user processes (it's UID 100 on my systems but other people will >have different numbers) and to specify the number of processes for users (it >would be a PITA if you hard-coded this into the kernel and then installed a >program which couldn't run properly without the number being increased). > Another thing I've been thinking about is the possibility of adding more >classes of users. EG Staff could be allowed to run more processes than average >users, but we still need some limits (can't give them no limits as we do with >system UIDs). > > What do you think? > > >Russell Coker > >
|  |