Date: Tue, 5 Jan 2016 21:09:11 -0700 From: Warner Losh <imp@bsdimp.com> To: Devin Teske <devin@shxd.cx> Cc: Bruce Evans <brde@optusnet.com.au>, Ian Lepore <ian@freebsd.org>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Devin Teske <dteske@freebsd.org> Subject: Re: svn commit: r293227 - head/etc Message-ID: <CANCZdfo97dq8x7_PLrcmE%2B0XaqskmiFOjUcBfVvP1UsaAWMzTg@mail.gmail.com> In-Reply-To: <5360EA7A-399F-4679-B58F-62D0112EA481@shxd.cx> References: <201601052120.u05LKlQw074919@repo.freebsd.org> <1452038404.1320.46.camel@freebsd.org> <20160106125617.E968@besplex.bde.org> <5360EA7A-399F-4679-B58F-62D0112EA481@shxd.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
The correct fix is
<maybe mount -uw>
chflags -R 0 firstboot
rm -rf firstboot
<maybe mount -ur>
If you still can't remove it, too bad. Checking to make sure it worked
really isn't
the unix way. Sometimes when you do stupid things, stupid results happen.
Warner
On Tue, Jan 5, 2016 at 8:16 PM, Devin Teske <devin@shxd.cx> wrote:
> This e-mail is extremely hard to parse and I think you are mistaken.
>
> The -f flag is more than just a counter to a possible -i
>
> Try to rm a file that has schg
> You will get a prompt without -i
> Adding -f will abate the prompt to attempt override of schg flag.
>
> There are more conditions in rm that lead to a prompt than simply those
> conditions involving -i and adding -f abates them all.
>
> --
> Devin
>
> > On Jan 5, 2016, at 6:48 PM, Bruce Evans <brde@optusnet.com.au> wrote:
> >
> > On Tue, 5 Jan 2016, Ian Lepore wrote:
> >
> >>> Log:
> >>> Use the more proper -f. Leave /bin/rm in place since that's what
> >>> other rc scripts have, though it isn't strictly necessary.
> >
> > "proper -f" is hard to parse. I think you mean:
> >
> > Use 'rm -f' to turn off -i in case rm is broken and is an alias which
> > has -i (and perhaps actually even something resembling rm) in it. More
> > precisely, use 'rm -f /usr/bin' to partly defend against the same bug
> > in /bin/rm (where it would be larger). Keep using /usr/rm instead of
> > restoring the use of plain rm since that is what other rc scripts have.
> > The previous change to use /bin/rm instead of plain rm was neither
> > necessary nor sufficient for fixing the bug. Neither is this one, but
> > it gets closer. It is a little-known bug in aliases that even absolute
> > pathnames can be aliased. So /bin/rm might be aliased to 'rm -ri /'.
> > Appending -f would accidentally help for that too, by turning it into
> > a syntax error, instead of accidentally making it more forceful by
> > turning -ri into -rf.
> >
> > Hopefully this is all FUD. Non-interactive scripts shouldn't source any
> > files that are not mentioned in the script. /etc/rc depends on a secure
> > environment being set up by init and probably gets it since init doesn't
> > set up much. sh(1) documents closing the security hole of sourcing the
> > script in $ENV for non-interactive shells, but was never a problem for
> > /etc/rc since init must be trusted to not put security holes in $ENV.
> > But users could put security holes in a sourced config file like
> > /etc/rc.conf.local.
> >
> >>> Modified: head/etc/rc
> >>> =====================================================================
> >>> =========
> >>> --- head/etc/rc Tue Jan 5 21:20:46 2016 (r293226)
> >>> +++ head/etc/rc Tue Jan 5 21:20:47 2016 (r293227)
> >>> @@ -132,9 +132,9 @@ done
> >>> # Remove the firstboot sentinel, and reboot if it was requested.
> >>> if [ -e ${firstboot_sentinel} ]; then
> >>> [ ${root_rw_mount} = "yes" ] || mount -uw /
> >>> - /bin/rm ${firstboot_sentinel}
> >>> + /bin/rm -f ${firstboot_sentinel}
> >>> if [ -e ${firstboot_sentinel}-reboot ]; then
> >>> - /bin/rm ${firstboot_sentinel}-reboot
> >>> + /bin/rm -f ${firstboot_sentinel}-reboot
> >>> [ ${root_rw_mount} = "yes" ] || mount -ur /
> >>> kill -INT 1
> >>> fi
> >>
> >> Using rm -f to suppress an error message seems like a bad idea here --
> >> if the sentinel file can't be removed that implies it's going to do
> >> firstboot behavior every time it boots, and that's the sort of error
> >> that should be in-your-face. Especially on the reboot one because
> >> you're going to be stuck in a reboot loop with no error message.
> >
> > Er, -f on rm only turns off -i and supresses the warning message for
> > failing to remove nonexistent files. But we just tested that the file
> > exists, and in the impossible even of a race making it not exist by
> > the time that it runs, we have more problems than the failure of rm
> > since we use the file's existence as a control for other things.
> >
> > So the only effect of this -f is to turn off -i, which can only be set
> > if the FUD was justified.
> >
> > The correct fix seems to be 'unalias -a'.
> >
> > Bruce
> >
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo97dq8x7_PLrcmE%2B0XaqskmiFOjUcBfVvP1UsaAWMzTg>