[nycbug-talk] Safety Expansion for FreeBSD rm(1)

[H. G.]

On 10/2/07, Nathan Boeger <nboeger at khmere.com> wrote:
>
> Steven Kreuzer wrote:
> > On Tue, Oct 02, 2007 at 02:22:46PM -0400, Nathan Boeger wrote:
> >
> >> Steven Kreuzer wrote:
> >>
> >>> Greetings-
> >>>
> >>> I am reading through the freebsd-current mailing list and I stumbled
> upon a
> >>> proposed patch that I thought was rather interesting
> >>>
> >>> Basically, is a patch to rm that first reads ~/.rm before actually
> removing
> >>> anything to make sure that what you are trying to delete isn't
> "protected"
> >>>
> >>> Example, if I did rm -rf ~ /bin (when I really wanted ~/bin) it would
> check
> >>> to make sure that /bin and ~ are allowed to be removed.
> >>>
> >>> I am kinda on the fence about this, but think it could be a useful way
> to
> >>> protect yourself from yourself
> >>>
> >>> Project Page: http://people.freebsd.org/~daichi/safety-rm/
> >>> eMail thread on freebsd-current:
> >>> http://marc.info/?l=freebsd-current&m=119072708632143&w=2
> >>>
> >>> What do you think?
> >>>
> >>>
> >>>
> >> So here is a few questions:
> >>
> >> 1. What if  someone aliased: cat /dev/null > ~/.rmrc?
> >>
> >
> > So you end up with a 0B regular file.
> >
> > while (fgets(line, sizeof(line), fp) != NULL)
> >
> > File is just opened and closed and rm continues on. This would almost be
> the
> > same as having no ~/.rm file.
> >
> Exactly, so some meanie could easily blow your file away. Or worse you
> could fat finger it and never know. So it offers little to no help.
> >> 2. What if rm is has setuid bit on it for some strange reason? Then
> >> would your ~/.rmrc still be read?
> >>
> >
> > rm is just reading the file, not executing it.
> >
> >
> No, what I mean is the binary rm has setuid not the ~/.rmrc file.
> >> 3. What if I dd if=/dev/random of=~/.rmrc  and make it some huge blob.
> >> Could this expose a buffer overun?
> >>
> >>
> > Anything is possible. Buffer overflows happens. You use best practices
> to
> > try and avoid them, but if they happen, you find the cause and patch it.
> >
> >
> Agreed, but going out of your way to potentially create them for no real
> benefit does not seem practical.
> >> 4. Will rm need to check if the ~/.rmrc is hard or soft linked?
> >>
> >>
> >
> > I just took a closer look at the patch. The original author only checks
> to
> > make sure the file is there, and if it is, makes sure it is owned by the
> user
> > and they have read access to it. Might make sense to throw in some
> checks to
> > make sure it is a regular file.
> >
> >
> Good idea, so what if the user is issuing rm -fR /dir/* that has a lot
> of files. Would you then check every time? Or would it fail for all?
> What about: for i in `ls /dir/' do rm $i; done?
>
> And if it took a lot of time to delete all those files and someone
> updated the ~/.rmrc before it was complete then what? Would that change
> not be reflected in the current rm process?
> >> 5. Would rm never be allowed to remove `/.rmrc or would you need to
> list
> >> it inside its own file?
> >>
> >>
> >
> > This might break the time continuum and can result to a time
> > paradoxon. Don't be suprised.
> >
> >
> Or worse it could rip a whole into fluidic space and unleash species 8472!
>
> I daresay that you guys have mistakenly stumbled onto the recipe for FTL
travel.
The hardest part is controlling the space fold caused using any ol' machine
running
CURRENT to rm its own ~/.rmrc.

Commendable, folks.  Physicists will be singing praises, and everyone
everywhere
will start to use FreeBSD for the new era that it has created for humanity.
Wait? Who am I kidding?  It'll just be a free-for-all as greedy folks rush
to claim
planets, and then we'll end up having yet another Empire vs. Colonies
Independence
War.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20071002/99f1fed0/attachment.htm>