Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!orion.oac.uci.edu!cedman From: cedman@lynx.ps.uci.edu (Carl Edman) Newsgroups: comp.sys.hp Subject: Re: Limiting the size of corefiles Message-ID: Date: 17 Oct 90 03:21:47 GMT References: <1990Oct15.171543.9516@ra.src.umd.edu> <4840@baird.cs.strath.ac.uk> <1990Oct16.115750.2291@vaxa.strath.ac.uk> Organization: non serviam Lines: 29 Nntp-Posting-Host: lynx.ps.uci.edu In-reply-to: cnbr10@vaxa.strath.ac.uk's message of 16 Oct 90 11:57:50 GMT 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.edu