bug#19262: rm command removes a read-only file without confirming when the stdin is closed

[Eric Blake]

tag 19262 notabug
thanks

On 12/03/2014 01:57 AM, Takahashi Mamoru wrote:
> Hello,
> 
> $ touch a; chmod 0444 a; ls -l a
> -r--r--r-- 1 foo bar 0 Dec  3 14:25 a
> 
> $ echo a | xargs /bin/rm -v
> removed 'a'

Thanks for the report.  This is NOT an instance of stdin being closed.
POSIX says for xargs:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/xargs.html

"The results are unspecified if the utility named by utility attempts to
read from its standard input" - but this means that xargs has a choice
of either passing the _same_ stdin to the child (so rm's stdin is a
pipe) or a different stdin such as /dev/null (but rm's stdin would still
not be closed, but just be something that reads EOF without corrupting
xargs' stdin).  But either way, the behavior of 'rm' that you see here
is required by POSIX:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html

Step 2.b.:
"If the -f option is not specified, and either the permissions of file
do not permit writing and the standard input is a terminal or the -i
option is specified, rm shall write a prompt to standard error and read
a line from the standard input...."

Rationale:
"For absolute clarity, paragraphs (2b) and (3) in the DESCRIPTION of rm
describing the behavior when prompting for confirmation, should be
interpreted in the following manner:

    if ((NOT f_option) AND
        ((not_writable AND input_is_terminal) OR i_option))"

Given that you did NOT use either -f nor -i, then the determination of
whether to warn on whether the file is read-only is based on whether
stdin is a terminal.  /dev/null is not a terminal.  Ergo, no prompt.
And it's a good thing too - since you would have undefined behavior if
'rm' _did_ attempt to read from the stdin that it inherited from xargs.

> 
> Or,
> 
> $ touch a; chmod 0444 a; ls -l a
> $ /bin/rm -v a 0<&-
> removed 'a'

This is undefined behavior, per POSIX (starting ANY application with
stdin closed is undefined; in some cases, the OS may choose to start the
app with stdin pointing to /dev/null instead of being closed, but you
can't rely on that happening).  But the answer is the same whether stdin
remains closed by the OS or whether it was opened to /dev/null - either
way, stdin is not interactive.

> 
> Is this a bug or a feature ?

Feature, mandated by POSIX (arguably an odd requirement, but it matches
historical practice that people have come to rely on, so we can't change
it).  Therefore, I'm closing this as not a bug, although you should feel
free to reply if you have further comments or questions.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature