GNU bug report logs - #15926
RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

Previous Next

Full log

Message #215 received at 15926 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 15926 <15926 <at> debbugs.gnu.org>
Subject: Re: bug#15926: RFE: unlink command already uses 'unlink' call; make
 'rm' use 'remove' call
Date: Sat, 30 Nov 2013 14:33:34 -0700

Pádraig Brady wrote:
> Bob Proulx wrote:
> > I still think this is a very scary test and isn't worth the return on
> > investment.  It is the kind of thing that makes me think I could never
> > recommend building coreutils anywhere but in a throwaway chroot.
> > Because the risk of a failure is just so very extremely high.  That
> > would be a shame.
> 
> To summarize, it,
> only runs with: make EXPENSIVE=yes check,
> only runs as non root,
> ensures file & dir removal bypass work in a safe context first

Plus I see a timeout too.  The timeout is a good safety net.  However
it does create some possibility for a false positive fail if the
system is slow.  But a possible FP is a minor thing.

I wasn't quite convinced that this is skipped if LD_PRELOAD isn't
supported by the system.  However I don't doubt it.  I just wasn't
able to trace through the logic by inspection quickly enough.

> Do you still think it's too dangerous?

I can't say that it isn't still scary.  There is an intentional
execution of an 'rm -r /'!  But looking at it I think you guys have
done a lot of work to make it as safe as possible.  I still think that
was way too much investment for the potential return.  But having done
it I can't say not to include it.  Since it only runs as non-root then
an accident there really isn't any worse than any other rm accident
that might happen.  But that is today in the current incarnation.

But for example what happens if the preferred unlink command ever
changes from unlinkat() to something new about ten years in the
future?  Can't say it won't change since we have already seen it
change.  If the code is changed in the future and the tests run then
what prevents the pitfall at that point in the future?

I really don't want to be a rainy day but I worry about these things.

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.