Re: svn commit: r293227 - head/etc

[Allan Jude]

On 2016-01-06 01:40, Bruce Evans wrote:

On Tue, 5 Jan 2016, Allan Jude wrote:


On 2016-01-05 22:16, Devin Teske 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.


I forgot about the permissions check.  Normally root has permission to
write anything, but some file flags change this.  The schg flag is
handled bogusly: rm prompts without -f, but schg prevents removal if
you answer 'y'.  The uchg flag is handled better.  rm has special
undocumented code to handle it, mainly so that rm -rf blows it away.
Without -f, rm prompts but the the special code removes uchg so that
removal is possible.

The permissions check only applies to the file.  Removal doesn't
depend on the file's permissions.  It only depends on the file's flags
and the directory's permissions and flags.  rm agrees with its man
page and doesn't prompt if the file is writable but the directory is
unwritable.  The directory permissions don't stop root either, but
immutable directories do.  Since there is no prompt, -f has no effect
on anyone in this case.


There are more conditions in rm that lead to a prompt than simply
those conditions involving -i and adding -f abates them all.


It isn't clear what these are.  POSIX only says that there is a prompt
without -i for files which don't have write permission (to themselves).
FreeBSD's man page should say more about how this extended for file
flags, but actually says nothing for file flags and is less clear than
POSIX for ordinary permissions.


I think this is kind of a poor UI design of rm(1) honestly. It seems
like what we need is a 'never be interactive' flag, that won't surpress
the error message about the schg'd file, or read-only file system, but
won't try to prompt for it.

Although adding a new flag to rm(1) at this point probably doesn't make
sense.


It already has this flag, namely -f.  This is what I started out to say.
-f never suppresses errors except ENOENT for a non-existent file.  What it
suppresses is prompts.  Since the uchg hack involves a prompt, -f also
changes the semantics for removing user-immutable files.

The file flags hack includes uappnd together with uchg, but not the
newfangled uunlnk.  That has only been available for annoying sysadmins
since 1997.  Apparently its name is to confusing for it to be used.

Bruce



In most of the cases involved in the firstboot script, the cause of the 
prompt is that the file system is mounted readonly. So Warner's solution 
of mounting the filesystem rw, doing the rm, then reverting it to 
readonly would seem to work, although I wonder if there is a case where 
the file system was NOT readonly at the start of the script, and ends up 
read only at the end.


--
Allan Jude
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Devin Teske]

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  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/rcTue Jan  5 21:20:46 2016(r293226)
>>> +++ head/etc/rcTue 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
> 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Devin Teske]

> On Jan 5, 2016, at 8:09 PM, Warner Losh  wrote:
> 
> The correct fix is
> 
> 
> chflags -R 0 firstboot
> rm -rf firstboot
> 
> 
> 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.
> 

You forgot to drop the mic and walk out. Looks good to me.
-- 
Devin


> Warner
> 
>> On Tue, Jan 5, 2016 at 8:16 PM, Devin Teske  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  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/rcTue Jan  5 21:20:46 2016(r293226)
>> >>> +++ head/etc/rcTue 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
>> >
> 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Allan Jude]

On 2016-01-05 22:16, Devin Teske 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.
> 

I think this is kind of a poor UI design of rm(1) honestly. It seems
like what we need is a 'never be interactive' flag, that won't surpress
the error message about the schg'd file, or read-only file system, but
won't try to prompt for it.

Although adding a new flag to rm(1) at this point probably doesn't make
sense.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r293227 - head/etc

[Warner Losh]

The correct fix is


chflags -R 0 firstboot
rm -rf firstboot


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  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  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/rcTue Jan  5 21:20:46 2016(r293226)
> >>> +++ head/etc/rcTue 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
> >
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Bruce Evans]

On Tue, 5 Jan 2016, Allan Jude wrote:


On 2016-01-05 22:16, Devin Teske 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.


I forgot about the permissions check.  Normally root has permission to
write anything, but some file flags change this.  The schg flag is
handled bogusly: rm prompts without -f, but schg prevents removal if
you answer 'y'.  The uchg flag is handled better.  rm has special
undocumented code to handle it, mainly so that rm -rf blows it away.
Without -f, rm prompts but the the special code removes uchg so that
removal is possible.

The permissions check only applies to the file.  Removal doesn't
depend on the file's permissions.  It only depends on the file's flags
and the directory's permissions and flags.  rm agrees with its man
page and doesn't prompt if the file is writable but the directory is
unwritable.  The directory permissions don't stop root either, but
immutable directories do.  Since there is no prompt, -f has no effect
on anyone in this case.


There are more conditions in rm that lead to a prompt than simply those 
conditions involving -i and adding -f abates them all.


It isn't clear what these are.  POSIX only says that there is a prompt
without -i for files which don't have write permission (to themselves).
FreeBSD's man page should say more about how this extended for file
flags, but actually says nothing for file flags and is less clear than
POSIX for ordinary permissions.


I think this is kind of a poor UI design of rm(1) honestly. It seems
like what we need is a 'never be interactive' flag, that won't surpress
the error message about the schg'd file, or read-only file system, but
won't try to prompt for it.

Although adding a new flag to rm(1) at this point probably doesn't make
sense.


It already has this flag, namely -f.  This is what I started out to say.
-f never suppresses errors except ENOENT for a non-existent file.  What it
suppresses is prompts.  Since the uchg hack involves a prompt, -f also
changes the semantics for removing user-immutable files.

The file flags hack includes uappnd together with uchg, but not the
newfangled uunlnk.  That has only been available for annoying sysadmins
since 1997.  Apparently its name is to confusing for it to be used.

Bruce
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Bruce Evans]

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
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r293227 - head/etc

[Warner Losh]

Author: imp
Date: Tue Jan  5 21:20:47 2016
New Revision: 293227
URL: https://svnweb.freebsd.org/changeset/base/293227

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.

Modified:
  head/etc/rc

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
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Ian Lepore]

On Tue, 2016-01-05 at 16:35 -0800, Devin Teske wrote:
> > On Jan 5, 2016, at 4:27 PM, Ian Lepore  wrote:
> > 
> > On Tue, 2016-01-05 at 19:18 -0500, Allan Jude wrote:
> > > On 2016-01-05 19:16, Devin Teske wrote:
> > > > 
> > > > > On Jan 5, 2016, at 4:00 PM, Ian Lepore 
> > > > > wrote:
> > > > > 
> > > > > On Tue, 2016-01-05 at 21:20 +, Warner Losh wrote:
> > > > > > Author: imp
> > > > > > Date: Tue Jan  5 21:20:47 2016
> > > > > > New Revision: 293227
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/293227
> > > > > > 
> > > > > > 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.
> > > > > > 
> > > > > > Modified:
> > > > > >  head/etc/rc
> > > > > > 
> > > > > > Modified: head/etc/rc
> > > > > > ===
> > > > > > 
> > > > > > ==
> > > > > > =
> > > > > > --- head/etc/rc Tue Jan  5 21:20:46 2016(r29
> > > > > > 3226
> > > > > > )
> > > > > > +++ head/etc/rc Tue Jan  5 21:20:47 2016(r29
> > > > > > 3227
> > > > > > )
> > > > > > @@ -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.
> > > > > 
> > > > 
> > > > Leaving off -f so that the user gets prompted isn't quite as
> > > > helpful
> > > > as, say, using -f but then testing to make sure the file is
> > > > really
> > > > gone
> > > > (if it still exists after a silent "rm -f", put up an
> > > > informative
> > > > warning
> > > > instead of asking the user if they would like to delete it).
> > > > 
> > > > The end-result of having something thrown in your face seems
> > > > desirable. Having a prompt that asks you if you'd like to
> > > > delete it
> > > > (even if there is an error immediately above it explaining it
> > > > could
> > > > not be deleted) seems nonsensical.
> > > > 
> > > 
> > > More specifically, firstboot is most likely run in situations
> > > where
> > > no 
> > > one will be at the console, so an interactive prompt stopping the
> > > system 
> > > from coming up is bad.
> > > 
> > 
> > I couldn't possibly disagree more.  If you're not paying attention
> > to
> > what happens the first time you boot a freshly installed system,
> > you
> > deserve whatever happens to you.
> 
> What if you are in New York and the server is alone in Siberia?
> 
> ... Got SSH? (not if your boot stopped, you don't)

Unh huh.  And what are you going to do when the server goes
unresponsive because it silently failed to delete firstboot-reboot and
now it's just in an endless reboot loop?

Silent failure is only a viable option for expected errors you can
recover from without intervention.

-- Ian

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Devin Teske]

> On Jan 5, 2016, at 4:00 PM, Ian Lepore  wrote:
> 
> On Tue, 2016-01-05 at 21:20 +, Warner Losh wrote:
>> Author: imp
>> Date: Tue Jan  5 21:20:47 2016
>> New Revision: 293227
>> URL: https://svnweb.freebsd.org/changeset/base/293227
>> 
>> 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.
>> 
>> Modified:
>>  head/etc/rc
>> 
>> 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.
> 

Leaving off -f so that the user gets prompted isn't quite as helpful
as, say, using -f but then testing to make sure the file is really gone
(if it still exists after a silent "rm -f", put up an informative warning
instead of asking the user if they would like to delete it).

The end-result of having something thrown in your face seems
desirable. Having a prompt that asks you if you'd like to delete it
(even if there is an error immediately above it explaining it could
not be deleted) seems nonsensical.
-- 
Devin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Allan Jude]

On 2016-01-05 19:16, Devin Teske wrote:



On Jan 5, 2016, at 4:00 PM, Ian Lepore  wrote:

On Tue, 2016-01-05 at 21:20 +, Warner Losh wrote:

Author: imp
Date: Tue Jan  5 21:20:47 2016
New Revision: 293227
URL: https://svnweb.freebsd.org/changeset/base/293227

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.

Modified:
  head/etc/rc

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.



Leaving off -f so that the user gets prompted isn't quite as helpful
as, say, using -f but then testing to make sure the file is really gone
(if it still exists after a silent "rm -f", put up an informative warning
instead of asking the user if they would like to delete it).

The end-result of having something thrown in your face seems
desirable. Having a prompt that asks you if you'd like to delete it
(even if there is an error immediately above it explaining it could
not be deleted) seems nonsensical.



More specifically, firstboot is most likely run in situations where no 
one will be at the console, so an interactive prompt stopping the system 
from coming up is bad.


--
Allan Jude
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Ian Lepore]

On Tue, 2016-01-05 at 19:18 -0500, Allan Jude wrote:
> On 2016-01-05 19:16, Devin Teske wrote:
> > 
> > > On Jan 5, 2016, at 4:00 PM, Ian Lepore  wrote:
> > > 
> > > On Tue, 2016-01-05 at 21:20 +, Warner Losh wrote:
> > > > Author: imp
> > > > Date: Tue Jan  5 21:20:47 2016
> > > > New Revision: 293227
> > > > URL: https://svnweb.freebsd.org/changeset/base/293227
> > > > 
> > > > 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.
> > > > 
> > > > Modified:
> > > >   head/etc/rc
> > > > 
> > > > 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.
> > > 
> > 
> > Leaving off -f so that the user gets prompted isn't quite as
> > helpful
> > as, say, using -f but then testing to make sure the file is really
> > gone
> > (if it still exists after a silent "rm -f", put up an informative
> > warning
> > instead of asking the user if they would like to delete it).
> > 
> > The end-result of having something thrown in your face seems
> > desirable. Having a prompt that asks you if you'd like to delete it
> > (even if there is an error immediately above it explaining it could
> > not be deleted) seems nonsensical.
> > 
> 
> More specifically, firstboot is most likely run in situations where
> no 
> one will be at the console, so an interactive prompt stopping the
> system 
> from coming up is bad.
> 

I couldn't possibly disagree more.  If you're not paying attention to
what happens the first time you boot a freshly installed system, you
deserve whatever happens to you.  On the other hand it's about the
worst to have everything silently seem to work right, and the actual
error is going to happen *next* time you boot (which is when it's
really likely you're not paying attention because everything seemed to
be okay the first time).

-- Ian

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Devin Teske]

> On Jan 5, 2016, at 4:27 PM, Ian Lepore  wrote:
> 
> On Tue, 2016-01-05 at 19:18 -0500, Allan Jude wrote:
>> On 2016-01-05 19:16, Devin Teske wrote:
>>> 
 On Jan 5, 2016, at 4:00 PM, Ian Lepore  wrote:
 
 On Tue, 2016-01-05 at 21:20 +, Warner Losh wrote:
> Author: imp
> Date: Tue Jan  5 21:20:47 2016
> New Revision: 293227
> URL: https://svnweb.freebsd.org/changeset/base/293227
> 
> 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.
> 
> Modified:
>  head/etc/rc
> 
> 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.
 
>>> 
>>> Leaving off -f so that the user gets prompted isn't quite as
>>> helpful
>>> as, say, using -f but then testing to make sure the file is really
>>> gone
>>> (if it still exists after a silent "rm -f", put up an informative
>>> warning
>>> instead of asking the user if they would like to delete it).
>>> 
>>> The end-result of having something thrown in your face seems
>>> desirable. Having a prompt that asks you if you'd like to delete it
>>> (even if there is an error immediately above it explaining it could
>>> not be deleted) seems nonsensical.
>>> 
>> 
>> More specifically, firstboot is most likely run in situations where
>> no 
>> one will be at the console, so an interactive prompt stopping the
>> system 
>> from coming up is bad.
>> 
> 
> I couldn't possibly disagree more.  If you're not paying attention to
> what happens the first time you boot a freshly installed system, you
> deserve whatever happens to you.

What if you are in New York and the server is alone in Siberia?

... Got SSH? (not if your boot stopped, you don't)
-- 
Devin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Ian Lepore]

On Tue, 2016-01-05 at 21:20 +, Warner Losh wrote:
> Author: imp
> Date: Tue Jan  5 21:20:47 2016
> New Revision: 293227
> URL: https://svnweb.freebsd.org/changeset/base/293227
> 
> 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.
> 
> Modified:
>   head/etc/rc
> 
> 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.

-- Ian

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r293227 - head/etc

[Devin Teske]

> On Jan 5, 2016, at 5:18 PM, Ian Lepore  wrote:
> 
> On Tue, 2016-01-05 at 16:35 -0800, Devin Teske wrote:
>>> On Jan 5, 2016, at 4:27 PM, Ian Lepore  wrote:
>>> 
>>> On Tue, 2016-01-05 at 19:18 -0500, Allan Jude wrote:
 On 2016-01-05 19:16, Devin Teske wrote:
> 
>> On Jan 5, 2016, at 4:00 PM, Ian Lepore 
>> wrote:
>> 
>> On Tue, 2016-01-05 at 21:20 +, Warner Losh wrote:
>>> Author: imp
>>> Date: Tue Jan  5 21:20:47 2016
>>> New Revision: 293227
>>> URL: https://svnweb.freebsd.org/changeset/base/293227
>>> 
>>> 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.
>>> 
>>> Modified:
>>> head/etc/rc
>>> 
>>> Modified: head/etc/rc
>>> ===
>>> 
>>> ==
>>> =
>>> --- head/etc/rc Tue Jan  5 21:20:46 2016(r29
>>> 3226
>>> )
>>> +++ head/etc/rc Tue Jan  5 21:20:47 2016(r29
>>> 3227
>>> )
>>> @@ -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.
>> 
> 
> Leaving off -f so that the user gets prompted isn't quite as
> helpful
> as, say, using -f but then testing to make sure the file is
> really
> gone
> (if it still exists after a silent "rm -f", put up an
> informative
> warning
> instead of asking the user if they would like to delete it).
> 
> The end-result of having something thrown in your face seems
> desirable. Having a prompt that asks you if you'd like to
> delete it
> (even if there is an error immediately above it explaining it
> could
> not be deleted) seems nonsensical.
> 
 
 More specifically, firstboot is most likely run in situations
 where
 no 
 one will be at the console, so an interactive prompt stopping the
 system 
 from coming up is bad.
 
>>> 
>>> I couldn't possibly disagree more.  If you're not paying attention
>>> to
>>> what happens the first time you boot a freshly installed system,
>>> you
>>> deserve whatever happens to you.
>> 
>> What if you are in New York and the server is alone in Siberia?
>> 
>> ... Got SSH? (not if your boot stopped, you don't)
> 
> Unh huh.  And what are you going to do when the server goes
> unresponsive because it silently failed to delete firstboot-reboot and
> now it's just in an endless reboot loop?
> 
> Silent failure is only a viable option for expected errors you can
> recover from without intervention.
> 

Your point is valid. However, I think it unwise to rely on this:

dteske@porridge w $ rm foo
override rw-rw-r--  dteske/dteske schg,uarch for foo? y
rm: foo: Operation not permitted

As you can see above, the prompt put forth by rm really has nothing to do with 
"failure" but rather it has performed a cursory check and is asking you if it 
is OK to proceed.

The condition in which rm puts forth the prompt is _NOT_ the condition in which 
you want to halt the boot process.

You're absolutely right that we ought to prevent an infinite reboot-cycle.
Relying on rm to do it by not using "-f" is the wrong approach.

This is the right approach:

rm -f "${firstboot_sentinel}-reboot"
if [ -e "${firstboot_sentinel}-reboot" ]; then
read -p "Ruh roh; I smell an infinite reboot in your future!" 
IGNORED
fi

(if lovable Scooby Doo had coded it)
Funny error message aside, I earnestly think that's the approach we should take.

...

Quick note, should the code be updated to handle this:

$ mkdir $firstboot_sentinel
$ mkdir !$-reboot
$ reboot

This too:

$ touch $firstboot_sentinel
$ chflags schg !$
$ touch !$-reboot
$ chflags schg !$
$ reboot


Both of which would lead to infinite reboot cycle.
-- 
Devin
___