root%bostonu.csnet@csnet-relay.arpa (BostonU SysMgr) (08/30/85)
(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
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/31/85)
> >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. I think we're having a communication snafu. IF the default ulimit is made INFINITE, THEN the site manager can set a finite ulimit in /etc/profile, since as you point out a non-privileged user can always REDUCE his ulimit. I want >>> AT&T <<< to CHANGE THE DEFAULT ulimit to be INFINITE instead of the current value of 1Mb or whatever. Is that clearer?
lee@eel.UUCP (08/31/85)
We have had enough pressure on the ulimit issue that in IN/ix (Interactive's SystemV based products) we provide a system-wide ulimit in /etc/environment processed by init, and a per-user ulimit in the "gecos" field of entries in /etc/passwd processed by login. Using /etc/profile works only if the users are forced to use sh as their login shell.
whp@cbnap.UUCP (W. H. Pollock x4575 3S235) (09/02/85)
[Question about how to administatively set the ulimit]
This isn't so hard to do, without changing ulimit code. Just use inittab to
set ulimit to some astronomical value at boot time (the line should have the
default rstate and an action of boot). Then set ulimit down to any desired
value in /etc/profile. Even changing the default value used by ulimit sounds
like a minor code change (if you have source of course).
Wayne Pollock {ihnp4}!cbnap!whpguy@sun.uucp (Guy Harris) (09/03/85)
> [Question about how to administatively set the ulimit] > > This isn't so hard to do, without changing ulimit code. Just use inittab to > set ulimit to some astronomical value at boot time (the line should have the > default rstate and an action of boot). Then set ulimit down to any desired > value in /etc/profile. Sorry, this won't work. The action in question will be spawned by "init" and be a child of "init". It will cheerfully set its own "ulimit" and that of all its children, and "init" will cheerfully ignore that change and pass the old stupid "ulimit" down to everything else it kicks off. The file size limit is like the current directory; you can't change it in a subprocess and expect it to affet you. > Even changing the default value used by ulimit sounds like a minor code > change (if you have source of course). It isn't hard once you find it. Just change the CDLIMIT parameter in <sys/param.h>. (This is in S5; S3 embedded the constant "1L << 11" into the source code of "main.c".) If you don't have source, you might get somebody to try to find where the number is hidden and patch it. Now, would somebody in the USDL *PLEASE* do the following: cd <wherever> get -e SCCS/s.param.h ed param.h /CDLIMIT/s/(1L<<11)/0x7fffffff/ w q delta SCCS/s.param.h Gave UNIX a sane initial ulimit value. ^D rm param.h get SCCS/s.param.h Guy Harris
levy@ttrdc.UUCP (Daniel R. Levy) (09/03/85)
In article <1140@brl-tgr.ARPA>, gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: >> > >I want >>> AT&T <<< to CHANGE THE DEFAULT ulimit to be INFINITE instead >of the current value of 1Mb or whatever. Is that clearer? Can someone tell me if this is possible to do in the kernel configuration files provided with the 3B2/300? The ones I have make no allusion to ulimit or ULIMIT but I was hoping there was some way to do this. Thanks. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer, my pets, my plants, my boss, or the | at&t computer systems division | s.a. of any computer upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!ihnp4!ttrdc!levy or: ..!ihnp4!iheds!ttbcad!levy
levy@ttrdc.UUCP (Daniel R. Levy) (09/05/85)
In article <2749@sun.uucp>, guy@sun.uucp (Guy Harris) writes: > >> Even changing the default value used by ulimit sounds like a minor code >> change (if you have source of course). > >It isn't hard once you find it. Just change the CDLIMIT parameter in ><sys/param.h>. (This is in S5; S3 embedded the constant "1L << 11" into >the source code of "main.c".) If you don't have source, you might get >somebody to try to find where the number is hidden and patch it. > >Now, would somebody in the USDL *PLEASE* do the following: > > cd <wherever> > get -e SCCS/s.param.h > ed param.h > /CDLIMIT/s/(1L<<11)/0x7fffffff/ > w > q > delta SCCS/s.param.h > Gave UNIX a sane initial ulimit value. > ^D > rm param.h > get SCCS/s.param.h > > Guy Harris Let me share my dirty little fix for this (and let Guy debunk it); it does not even require patching a binary. # mv /etc/getty /etc/getty.x # cat > /etc/getty ulimit 4096 # OR WHATEVER exec /etc/getty.x $* ^D # chmod 544 /etc/getty # exit login: joeuser Password: motd etc. $ ulimit 4096 $ Note: if you have uugetty on some ports you will need to do a similar thing for it. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer, my pets, my plants, my boss, or the | at&t computer systems division | s.a. of any computer upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!ihnp4!ttrdc!levy or: ..!ihnp4!iheds!ttbcad!levy
robin@medstar.UUCP (Robin Cutshaw) (09/05/85)
If you aren't squeemish about adb'ing the kernel, one might look at the
relative offset of u.u_limit in user.h and then adb the kernel starting
at main, looking for usage of this offset. It seems that in "hand-crafting"
process zero, the system-wide ulimit is set (since the ulimit for a process
is inherited from its parent). This value is typically set up in the first
few lines of main. (This is how I posted the previous patch to Xenix).
-robin
--
----
Robin Cutshaw Dir. R&D MedSTAR, inc. (404) 325-2441
uucp: ...!{akgua,gatech}!medstar!robin