Subject: Re: core dump filename format
To: Robert Elz <kre@munnari.OZ.AU>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: tech-userlevel
Date: 09/07/1999 17:34:55
On Wed, Sep 08, 1999 at 12:46:55AM +1000, Robert Elz wrote:
> This is a cute idea, and all that, and is certainly implementable, but
> is it really a good idea?   Is there any real demand for it?

Yes, some peoples were using symlinks to get core dumps in another place
than the current directory.
And I think I'd also love to have all core dumps from one system in the same
place. When X (launched from xdm) leaves a core in /, filling up my
/ partition, bad things happens.

> 
> Further, you have just spent some time to fix the kernel so random root
> processes can't be fooled into dumping core in "bad" places - now there's
> this proposal to add a new inherited attribute which will allow people to
> arrange for core files from processes creates sometime much later to
> get dropped in all kinds of weird locations.

The core file follows the filesystem security semantics, if it get created
then the user would have been able to create any file here.
There's just the deal with suid binaries, but the machinery for tacking care
of this is already here.

> New inherited properties
> need to be considered very carefully, because if they're even slightly
> open to abuse, then someone later has to race around and find all the
> places that they can be abused, and find a method for avoiding the
> possibility for harm.
> 
> I think I'd just leave things as they are now - or if you like, make a per
> user (per process I mean of course) boolean for the name.core or just core
> choice, so people can choose which they prefer (I always preferred just
> core - it is easier to clean up).  That would seem safe enough.   But
> being able to route core files to random stray destinations and names seems
> a bit risky to me.

Well, if really this makes some peoples feel nervous, then we could have
just a global variable, or a way to dissallow changes of  the per-process
attribue (maybe securelevel == 2). But this feature is usefull, and I think
allowing users to change it too.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--