Date: Tue, 5 Jan 2016 21:10:52 -0800 From: Devin Teske <devin@shxd.cx> To: Warner Losh <imp@bsdimp.com> 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: <E1E299EF-CCCA-4A49-A516-FC0C700D9A0E@shxd.cx> In-Reply-To: <CANCZdfo97dq8x7_PLrcmE%2B0XaqskmiFOjUcBfVvP1UsaAWMzTg@mail.gmail.com> References: <201601052120.u05LKlQw074919@repo.freebsd.org> <1452038404.1320.46.camel@freebsd.org> <20160106125617.E968@besplex.bde.org> <5360EA7A-399F-4679-B58F-62D0112EA481@shxd.cx> <CANCZdfo97dq8x7_PLrcmE%2B0XaqskmiFOjUcBfVvP1UsaAWMzTg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 5, 2016, at 8:09 PM, Warner Losh <imp@bsdimp.com> wrote:
>=20
> The correct fix is
>=20
> <maybe mount -uw>
> chflags -R 0 firstboot
> rm -rf firstboot
> <maybe mount -ur>
>=20
> If you still can't remove it, too bad. Checking to make sure it worked rea=
lly isn't
> the unix way. Sometimes when you do stupid things, stupid results happen.
>=20
You forgot to drop the mic and walk out. Looks good to me.
--=20
Devin
> Warner
>=20
>> 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.
>>=20
>> The -f flag is more than just a counter to a possible -i
>>=20
>> 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.
>>=20
>> There are more conditions in rm that lead to a prompt than simply those c=
onditions involving -i and adding -f abates them all.
>>=20
>> --
>> Devin
>>=20
>> > 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 an=
y
>> > files that are not mentioned in the script. /etc/rc depends on a secur=
e
>> > 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
>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >>> --- 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} =3D "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} =3D "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
>> >
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1E299EF-CCCA-4A49-A516-FC0C700D9A0E>