Have you thought about just turfing those users who won't play by the rules?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Brian T.
Schellenberger
Sent: July 12, 2000 8:38 PM
To: [EMAIL PROTECTED]
Subject: Re: [expert] backround processes
Deryk Barker wrote:
>
> Thus spake Ellick Chan ([EMAIL PROTECTED]):
> [...]
> > If I remember correctly, ulimit has a rather poor manpage.
>
> I'll say. Basically it says see bash.
Which limits its utility a bit. I, for one, get:
> ulimit
ulimit: Command not found.
Why? Becuase I use tcsh . . .
Besides the whole ulimit thing, as noted elsewhere--indeed the idea of
banning all background process--makes an awful lot of Unix rather
useless. Unix is designed for forking process, and this happens in lots
of places where you might not expect it.
Perhaps the original poster could clarify just why he wants to do this?
If it's really only specific applications you want to limit, then either
delete them from the system or deny execute permissions to world, and
add the "blessed users" to whatever group you assign to those files.
If you truly want to ban "&" then the only way to do that is to get the
source to bash (or whatever shell you choose) and delete the code that
handles the "&" character. This will still break programs written in
shell script that use &, but most programs will be ok because they will
call fork() explicitly.
Then you'd have to remove (or deny permissions to) all other editors on
your system.
You'd also have to remove the c compiler (and probably perl and other
languages as well) since they could still write a fork() function
themselves. And prevent access to the internet, for with such access
they could download working versions of all the stuff you were busy
trying to break . . .
And all this just to remove functionality that's fundamental to Unix.
Ah dunno. Seems odd to me . . .
>
> > It can control
> > mem usage/processes, but is enforced by your shell(bash). I was trying
to
> > use it to control runaway processes such as Netscape, and nasty cookbook
> > lockups such as a fork bomb or malloc bomb. I think that if
> > a program tries to fork bomb in a clever way, or a malloc bomb, it may
be
> > able to act faster than the shell can stop it.
>
> I had to use this recently because we had students writing forking lab
> assignments which ran away. ulimit did actually control this.
>
> --
> |Deryk Barker, Computer Science Dept. | Music does not have to be
understood|
> |Camosun College, Victoria, BC, Canada| It has to be listened to.
|
> |email: [EMAIL PROTECTED] |
|
> |phone: +1 250 370 4452 | Hermann Scherchen.
|
--
"Brian, the man from babble-on" [EMAIL PROTECTED]
Brian T. Schellenberger http://www.babbleon.org
Support http://www.eff.org. Support decss defendents.
Support http://www.programming-freedom.org. Boycott amazon.com.
