rm prompt when deleting unwritable files

Question

This is about GNU rm. The info page says:

Otherwise, if a file is unwritable, standard input is a terminal, and the -f or --force option is not given, or the -i or --interactive=always option is given, rm prompts the user for whether to remove the file. If the response is not affirmative, the file is skipped.

• Is this GNU only?

• When using rm as root this does not happen on my system. Is this normal behavior? I can't find it documented anywhere.

• What's the rationale for this behavior? It only increases the confusion of users, who tend to think that you need to have write permissions for a file to delete it. It makes them think that rm chmods the file. But rm can also delete the file if one isn't the owner.

Answer 1

Since you asked three separate questions, I'll answer them separately.

Your first question:

Is this GNU only?

I'm not sure that it's GNU only. It seems to be a feature of GNU Coreutils' rm that is also found in at least some other rm documentation. For example, according to some old documentation at opengroup.org for POSIX rm:

3. If file is not of type directory, 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 the standard error and read a line from the standard input. If the response is not affirmative, rm shall do nothing more with the current file and go on to any remaining files.

Sound familiar? It's worded pretty closely to the GNU rm documentation you mentioned in your question.

---

Your second question:

When using rm as root this does not happen on my system. Is this normal behavior? I can't find it documented anywhere.

If you mean that running rm with no flags as root does not prompt you when trying to remove an "unwritable file", then yes, this is normal behavior for GNU Coreutils 8.23 (and probably almost every other version of GNU Coreutils). There doesn't seem to be any documentation for it, but if you dig into the source for rm (you've gotta bounce between several files to piece it all together), it shows that running rm somefile from a terminal as the root user will remove somefile without a prompt, even if it's write protected.

---

Your third question:

What's the rationale for this behavior? It only increases the confusion of users, who tend to think that you need to have write permissions for a file to delete it. It makes them think that rm chmods the file. But rm can also delete the file if one isn't the owner.

If you mean why can a user delete a write-protected file that they do not own, that behavior has less to do with rm and more to do with filesystem permissions. See linuxdevcenter.com, cyberciti.biz, and Wikipedia, which collectively state (more or less):

Usually, on most filesystems, deleting a file requires write permission on the parent directory (and execute permission, in order to enter the directory in the first place), but you need not have permission on the file itself. Note that, confusingly for beginners, permissions on the file itself are irrelevant. However, GNU rm asks for confirmation if a write-protected file is to be deleted, unless the -f option is used.

The bold emphasis is mine. This is how Linux and other Unix-like OSes handle file deletions based on file permissions.

Answer 2

plain user

You might wish to protect a file from your own deletion/modification. A quick way is to chmod 000 foo (or chmod -w foo). However, this is of no use if you choose to delete it unwillingly.

So rm command will inform you (as non root), if this is the case, that's why there is a confirmation request.

root

when running as root, an specially during batch/automatic procedures,

1. you are supposed to know what you are doing.
2. many shell might hang if confirmation is asked.

as a consequence, file are deleted "on sight".

confirmation

confirmation can be request (-i) or turn off (-f)

• -i is default for plain user.
• -f is default for root.

Answer 3

Is this GNU only?

No. This rm behavior dates back around 40 years and has been standardized.

What's the rationale for this behavior?

From the 1st edition man page for rm:

Removal of a file requires write permission in its directory, but neither read nor write permission on the file itself.

BUGS
rm probably should ask whether a read--only file is really to be removed.

The implication, I think, is that if a user wanted to protect a file against accidental writing by changing its mode to be read-only, then it was worth making an attempt to protect it from accidental deletion.

The TUHS archive is missing the 2nd edition man pages and rm source, but the 3rd edition man page for rm shows this had been addressed:

If there is no write permission to a file designated to be removed, rm will print the file name, its mode and then read a line from the standard input. If the line begins with 'y', the file is removed, otherwise it is not. The optional argument -f prevents the above interaction.

Unix and most of its commands eventually got standardized, and that's why rm behaves this way today.

When using rm as root this does not happen on my system. Is this normal behavior?

Not at first, but it is normal behavior now.

The earliest source code I can find is from V5:

    if(getuid() == buf->uid)
        b = 0200; else
        b = 2;
    if((buf->mode & b) == 0)    {
        printf("%s: %o mode ", arg, buf->mode);
        i = b = getchar();
        i = b;
        while(b != '\n' && b != '\0')
            b = getchar();
        if(i != 'y')
            return;
    }

which shows the writability check looks at the write permission by owner flag if the user running rm owns the file, otherwise the write permission by others flag.

In V7, rm was changed to use the newly-added access system call:

    if (access(arg, 02)<0) {
        printf("rm: %s %o mode ", arg, buf.st_mode&0777);
        if(!yes())
            return;
    }

Since access considers root to have write access to any file (unless it's on a read-only filesystem), rm will typically not ask for confirmation when it's run by root.