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