[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use
From: |
Bob Proulx |
Subject: |
bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call |
Date: |
Sat, 30 Nov 2013 14:33:34 -0700 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, (continued)
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Bernhard Voelker, 2013/11/25
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Bernhard Voelker, 2013/11/26
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Pádraig Brady, 2013/11/26
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Bernhard Voelker, 2013/11/27
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Pádraig Brady, 2013/11/28
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Bernhard Voelker, 2013/11/29
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Eric Blake, 2013/11/22
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Bob Proulx, 2013/11/29
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Pádraig Brady, 2013/11/29
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Eric Blake, 2013/11/30
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call,
Bob Proulx <=
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Bernhard Voelker, 2013/11/30
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Pádraig Brady, 2013/11/22
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Jim Meyering, 2013/11/22
- bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Bernhard Voelker, 2013/11/22
bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call, Eric Blake, 2013/11/21