Ulimits strikes again (SYSV)

[BostonU SysMgr]

(Doug Gwyn writes:)
>ulimit strikes again.  The default ulimit should be OFF (perhaps -1
>should mean this); the site manager can set a ulimit in /etc/profile
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>according to site needs.  I hope somebody FIXES this nuisance.

Nope, I think you lose again. Unless I am mistaken (we just went thru
this on our site) /etc/profile runs non-priv'd so it can't up your
ulimit, just lower it. You can't write a setuid program as ulimit is
on a per-process basis, in short, if you don't have the sources you
lose big, the only out would be to write a little setuid thing that
ups the ulimit and then forks a shell (after de-setuid'ing) for the
person and their higher ulimit would remain in effect for the life
of the subshell, pretty sleazy, but not fatal.

The correct thing would be there should be no ulimit to start (we
all agree on this one) and then the SA could SET IT DOWN if need
be by any algorithm they like in /etc/profile, for example, we do
this for students in general cuz w/o disk quotas on SYSV runaway
programs can cripple the system by filling disk, with a line like:

	if [ `uid` gt 1000]; then ulimit 2048

or some such (uid is a proggie that just printfs the uid.)

I will use this opportunity to once again raise a voice to ATTIS:
[flame on]
	EVEN WITH BINARY ONLY SYSTEMS GIVE OUT A FEW CRITICAL SOURCES

like login.c, getty.c and init.c, maybe a few others. It wouldn't kill
you I don't think or bring the house crashing down, you just cannot
expect to anticipate all the needs in regards to systems security and
integrity, I don't like the idea of being limited by someone else's
imagination. As far as the counter argument as to where to stop,
personal philosophy aside, anything would be better than this!
[flame off]
We decided to fix login.c, but we can. It could have been fixed in the
kernel, we may go to that but this was quick and easy.

	-Barry Shein, Boston University