linux-kernel - Re: [PATCH -v2] vfs: make unlink() return ENOENT in preference to EROFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Jun 2011 02:48:06 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	Theodore Ts'o <tytso@....edu>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, lacombar@...il.com
Subject: Re: [PATCH -v2] vfs: make unlink() return ENOENT in preference to
 EROFS

07.06.2011 02:30, Al Viro wrote:
> On Mon, Jun 06, 2011 at 04:58:13PM -0400, Theodore Ts'o wrote:
>> If user space attempts to unlink a non-existent file, and the file
>> system is mounted read-only, return ENOENT instead of EROFS.  Either
>> error code is arguably valid/correct, but ENOENT is a more specific
>> error message.
> 
> Umm...  I can live with that.  What about rmdir(2)?  We have similar situation
> there as well.  If we care about one, why not the other?

I think both should be fixed.

> Mind you, I'm not at all convinced that it matters enough to bother, but
> yes, ENOENT is a bit more specific (and likelier to be handled by luserland
> code).

The problem which triggered the initial thread and Ted's patch was me
trying to commit some changes from read-only /etc into git tree.  This
works for everything but deletes, since `git rm' barfs when unlink for
a non-existing file returns EROFS.  rm(1) has been patched especially
for this case at about kernel 2.6.32 time, as shown in comments at
 http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/remove.c#n450 ,
but git has not (yet), and I suspect git isn't the only leftover, there
are other applications to patch still, if the kernel will continue to
return EROFS.

Besides, POSIX says (http://pubs.opengroup.org/onlinepubs/009695399/functions/unlink.html):

  [EROFS]
    The directory entry to be unlinked
    is part of a read-only file system

so it clearly states that the entry should exists for EROFS, ie, to
be _part_ of the filesystem.

Thanks!

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/