Re: [PATCH 1/1] lib/bb/utils: add safeguard against recursively deleting things we shouldn't

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2015-04-20 at 14:59 +0100, Paul Eggleton wrote:
> On Monday 20 April 2015 09:46:19 Trevor Woerner wrote:
> > On 15-04-17 10:26 AM, Paul Eggleton wrote:
> > > Add some very basic safeguard against recursively deleting paths such
> > > as / and /home in the event of bugs or user mistakes.
> > 
> > I liked Nicolas Dechesne's idea of only allowing deletion in paths that
> > include TMPDIR or TOPDIR. Is there any reason bitbake would need to
> > delete (potentially dangerous) paths anywhere else?
> 
> Unfortunately this would be problematic for people who decide to split out 
> directories managed by the build system to different paths (which they often do 
> when part of the system has to be shared over NFS, or to put part of TMPDIR on 
> a larger disk, or spread between SSDs and rotational media, etc.). Another 
> issue is that the functions in question don't actually have access to d (the 
> datastore) and thus can't actually get the value of these variables, at least 
> with the way the code is currently structured.
> 
> > With a list-based approach the list will keep growing indefinitely.
> > Inevitably an ex-Solaris person will come along (for example) and have
> > their /home directories in /export/home and need a patch for that, etc,
> > etc...
> 
> It's not all-encompassing, I agree. I'm all for improving it but unfortunately 
> restricting to TMPDIR/TOPDIR will break for a lot of users.

I liked his idea too however we use these functions against SSTATE_DIR
and DL_DIR which are often not in TMPDIR/TOPDIR. Yes, we could start
making a list of exceptions but I don't think it will scale well, not
withstanding the other technical issues Paul mentions.

Cheers,

Richard