preetham@ra.src.umd.edu (10/16/90)
How does one suppress generation of a corefile (other than writing perfect programs of course) ?????? I usually do not use my corefile and I would like to limit the size of the file to 0 or not generate it at all. On the SUNs, this can be done including the line "limit coredumpsize 0", However on the HP's I am unable to find an equivalent. Any help would be greatly appreciated. Preetham Gopalaswamy
al@cs.strath.ac.uk (Alan Lorimer) (10/16/90)
In article <1990Oct15.171543.9516@ra.src.umd.edu> preetham@ra.src.umd.edu writes: > >How does one suppress generation of a corefile (other than writing perfect >programs of course) ?????? How about: ls -s /dev/null core To automatically `bin' them. Alan -- ____________________________________________________________________________ Alan G. Lorimer, Strathclyde University, 26 Richmond Street, Glasgow G1 1XH. UUCP: ...!uunet!mcvax!ukc!strath-cs!al DARPA: al%cs.strath.ac.uk@nsf.ac.uk Tel. +44 41 552 4400 Ext. 3592 JANET: al@uk.ac.strath.cs
al@cs.strath.ac.uk (Alan Lorimer) (10/16/90)
In article <4840@baird.cs.strath.ac.uk> al@cs.strath.ac.uk (Alan Lorimer) writes: >In article <1990Oct15.171543.9516@ra.src.umd.edu> preetham@ra.src.umd.edu writes: >How about: > > ls -s /dev/null core ^^ Quite right bruce, of course I mean `ln -s /dev/null core' Alan -- ____________________________________________________________________________ Alan G. Lorimer, Strathclyde University, 26 Richmond Street, Glasgow G1 1XH. UUCP: ...!uunet!mcvax!ukc!strath-cs!al DARPA: al%cs.strath.ac.uk@nsf.ac.uk Tel. +44 41 552 4400 Ext. 3592 JANET: al@uk.ac.strath.cs
cnbr10@vaxa.strath.ac.uk (10/16/90)
In article <4840@baird.cs.strath.ac.uk>, al@cs.strath.ac.uk (Alan Lorimer) writes: > In article <1990Oct15.171543.9516@ra.src.umd.edu> preetham@ra.src.umd.edu writes: >> >>How does one suppress generation of a corefile (other than writing perfect >>programs of course) ?????? > > How about: > > ls -s /dev/null core > > To automatically `bin' them. > > Alan > -- This should be: ln -s /dev/null core But another way (clue in the manual page for core (man 4 core)) is to chown the executable to some miscellaneous uid and gid, then make the file SUID to that user. The manual page says that "A process with an effective user ID different from the real user ID will not produce a core image." So the logic is that running a program suid to another user will not produce a core dump.... Haven't tested it...and I suppose it's ALWAYS fatal to believe the manual pages....but...maybe it's worth a try... David _______________________________________________________________________________ /~\ Never Trust An | CNBR10 Corp., VAX/VMS and UNIX Consultants /@@-\____--- Elephant In | "Pay up or we send the boys round to wipe / / / \ Dark Glasses. | your system disk" l/'\ /__\ /\, | \l lll lll | Service with a smile. :-) __~_"""___"""__________________________________________________________________
ted@hpwrce.HP.COM ( Ted Johnson) (10/17/90)
>On the SUNs, this can be done including the line >"limit coredumpsize 0", >However on the HP's I am unable to find an equivalent. The hack I've always used is to (as root) create an empty file ("touch core"), and remove write permission to it. Of course, this won't work if the program being debugged is run as root. -Ted #include <std.disclaimer.h>
pld@hpfcso.HP.COM (Paul Dineen) (10/17/90)
> How does one suppress generation of a corefile (other than writing perfect
I'd like to know that too. Until then, a workaround is to create a
directory named "core" in your pwd that you can't write to. Of
course, you'd need to do that in each directory you dump core into.
dr--r--r-- 2 pld guest 64 Sep 5 1989 corecedman@lynx.ps.uci.edu (Carl Edman) (10/17/90)
In article <1990Oct16.115750.2291@vaxa.strath.ac.uk> cnbr10@vaxa.strath.ac.uk writes:
But another way (clue in the manual page for core (man 4 core)) is to
chown the executable to some miscellaneous uid and gid, then
make the file SUID to that user.
The manual page says that "A process with an effective user ID different
from the real user ID will not produce a core image."
So the logic is that running a program suid to another user will not
produce a core dump....
Haven't tested it...and I suppose it's ALWAYS fatal to believe the manual
pages....but...maybe it's worth a try...
Yes, this behavior is really necessary. Otherwise it would be gaping
hole in the security of the system (security holes in HP-UX, no,
unimagineable :-). The whole point about suid-programs is that they
can access data which the user (with another program) can't. Much of
that data could be (at least temporarily) in memory. If I want to
gain access to this data, I could simply cause the program to core
dump while the data is still in memory and then just run a
debugger on the core-file and get , et voila !, the data. Thus
this is really necessary.
Carl Edman
Theorectial Physicist,N.:A physicist whose | Send mail
existence is postulated, to make the numbers | to
balance but who is never actually observed | cedman@golem.ps.uci.edu
in the laboratory. | edmanc@uciph0.ps.uci.edujohn@hpucph.dmk.hp.com (John Damm Srensen) (10/17/90)
/ hpucph:comp.sys.hp / preetham@ra.src.umd.edu / 7:15 pm Oct 15, 1990 / How does one suppress generation of a corefile (other than writing perfect programs of course) ?????? Try with a corefile like this in your working directory: ---------- 1 john other 0 Oct 17 11:37 core This prevents core dumping on my series 300 and series 800 systems running 7.0 . John Damm SVrensen Danish Response Center john%hpucph@hplabs.hp.com
aaa@hpuerca.HP.COM (Simon Fowler) (10/17/90)
>> How does one suppress generation of a corefile (other than writing perfect > > I'd like to know that too. Until then, a workaround is to create a > directory named "core" in your pwd that you can't write to. Of > course, you'd need to do that in each directory you dump core into. > > dr--r--r-- 2 pld guest 64 Sep 5 1989 core >---------- It does not have to be a directory - a regular file will do. simon
jimp@cognos.UUCP (Jim Patterson) (10/17/90)
In article <4840@baird.cs.strath.ac.uk> al@cs.strath.ac.uk (Alan Lorimer) writes: >In article <1990Oct15.171543.9516@ra.src.umd.edu> preetham@ra.src.umd.edu writes: >> >>How does one suppress generation of a corefile (other than writing perfect >>programs of course) ?????? > >How about: > > ls -s /dev/null core > >To automatically `bin' them. This appears as if it will work, but I'll bet it will still take a bit of time to 'bin' then when a large program bombs. It might be better to create a core file and change permissions so you can't write to it, forcing a write error when the core dump is attempted, as in touch core chmod a-rw core This work for me, and instead of saying Bus error (core dumped) HP-UX just says Bus error -- Jim Patterson Cognos Incorporated UUCP:uunet!mitel!cunews!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive NOT a Jays fan (not even a fan) Ottawa, Ont K1G 3Z4
brians@hpcljms.HP.COM (Brian Sullivan) (10/18/90)
>> >>How does one suppress generation of a corefile (other than writing perfect >>programs of course) ?????? > >How about: > > ls -s /dev/null core ^^ should be `ln' not `ls' > >To automatically `bin' them. > >Alan Another way is to touch ./core chmod 0 ./core This create an unwritable/undeletable file called core. -- Brian --
bruce@hpihoah.cup.hp.com (Bruce LaVigne) (10/19/90)
> > I'd like to know that too. Until then, a workaround is to create a > > directory named "core" in your pwd that you can't write to. Of > > course, you'd need to do that in each directory you dump core into. > > > > dr--r--r-- 2 pld guest 64 Sep 5 1989 core > >---------- > > It does not have to be a directory - a regular file will do. > > simon > ---------- It does not have to be non-writable if it is a directory though, so often I do a: mkdir core in directories I am running in. That way, even if running as root which might be allowed to write to non-writable files, it cannot put a file onto a directory... -bruce Disclaimer: My opinions only. This is not an HP response, official or otherwise