It's implementable. The kernel needs a "struct userinfo" per logged-in =
user=20
for that to work. The same structure could also hold total memory usage=
,
which would enable us to finally block most of the more malicious
fork/malloc bombs.
> of CPU use per user", I don't see why this couldn't be better done in=
user
> space... unless you mean absolute, cumulative time spent by the CPU f=
or that
> user only -- and you can, say, ftp for a _long_ time (with a 14.4 any=
way)
> before you show significant time on "top". -- most users won't be doi=
ng
> really intensive stuff.
>=20
I don't think that's too useful. We can already count how much CPU the =
user
burned. Capping the amount of "live" memory for the user (so as to prev=
ent=20
a "mmap() as much of /dev/zero as we're allowed to, and then randomly
write to bytes thereof" attack) would be better.
But then, if you have that kind of user population where this is a
significant problem, your money is better spent on educating these guys=
to
Not Do That (and kick the few people who can't understand the words "ce=
ase
and desist" off the system).
--=20
It were better to perish than to continue schoolmastering.
-- Thomas Carlyle
--=20
Matthias Urlichs \ noris network GmbH / Xlink-POP N=FCrnberg=
=20
Schleiermacherstra=DFe 12 \ Linux+Internet / EMail: urlichs@nor=
is.de
90491 N=FCrnberg (Germany) \ Consulting+Programming+Networking+etc=
'ing
PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 D=
E
Click <A HREF=3D"http://info.noris.de/~smurf/finger">here</A>. =
42