[bitbake-devel] [PATCH 1/1] lib/bb/utils: add safeguard against recursively deleting things we shouldn't
Richard Purdie
richard.purdie at linuxfoundation.org
Mon Apr 20 22:04:53 UTC 2015
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
More information about the bitbake-devel
mailing list