* Jim B said: > On Mon, 10 Jan 2000, Ethan Benson wrote: > > > ulimit does not really protect at all against someone malicious since > > they are perfectly free to un-ulimit themselves, this is where > > pam_limits is helpful, it enforces the hard limit and it cannot be > > ulimited past that. > > Hmmm. How would a user "unlimit himself" without changing his shell? If > he stays in a single bash or csh shell, I don't know how he could do that. He can't, true. But shell-based limits aren't particularily good way of setting limits. They are by definition bound to one kind of shell - csh or bash or whatever. In case you, or the user, decideds to change his shell, you loose all the limits. PAM and/or shadow utilities (or lshell) are much better.
[snip] > OTOH if you're talking about someone who switches his shell to get around > the limits, that's my whole point. I need to know how to set > shell-independent limits. Yes you can do that with PAM, but I still don't > see a PAM limit on virtual memory. Is there one there? Compute the ULIMIT value and put it in the commen't field of the user's record in the password database (ulimit=ULIMIT_VALUE). Then the login process will set the limits regardless of the shell. And if you worry about the user changing shell during the session - don't. The child process whether spawned or executed, will inherit the limits from its parent. marek
pgpobnffszbRZ.pgp
Description: PGP signature
