linux-kernel - Re: Race-free unlinking of directory entries

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] [day] [month] [year] [list]

Date:   Mon, 1 Oct 2018 22:26:57 +0200
From:   Pali Rohár <pali.rohar@...il.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Jan Kara <jack@...e.cz>
Subject: Re: Race-free unlinking of directory entries

On Monday 09 April 2018 12:35:54 Pali Rohár wrote:
> On Monday 09 April 2018 03:24:14 Christoph Hellwig wrote:
> > On Mon, Apr 09, 2018 at 12:10:09PM +0200, Pali Rohár wrote:
> > > Another example:
> > > 
> > > fd = open("/a")
> > > link("/a", "/b")
> > > unlink("/a")
> > > 
> > > Calling funlink for fd should unlink "/b" or it should fail?
> > 
> > It should fail, as '/a' doesn't refer to name that is visible in the
> > namespace.
> > 
> > > And another example:
> > > 
> > > fd = open("/a")
> > > rename("/a", "/b")
> > > 
> > > What should funlink do for fd now?
> > 
> > remove the directory entry refering to '/b' as that is what fd refers
> > to.
> 
> Why it should differ in these two cases? Calling /bin/ln /a /b followed by
> /bin/rm /a results in the same state as calling /bin/mv /a /b. This is
> something which works in POSIX systems.
> 
> I think it is strange that new possible funlink call would work only if
> external applications uses /bin/mv and would fail if /bin/ln and /bin/rm
> are used.
> 
> This is reason why I suggested two parameters funlink, it takes fd for
> unlinking and pathname which must contain same inode as fd. So when you
> call it with fd+"/b" it unlink "/b" without failing.

Imagine that you have opened file descriptor in your program and you
want to unlink file behind that file descriptor.

Now some external process rename that file via rename() syscall and
based on your argument unlinking file descriptor in your program pass.

But if that external process do link() syscall followed by unlink()
syscall -- to simulate rename operation -- then based on your argument
unlinking file descriptor in your program fails.

I think this is really inconsistency which is not so good.

...

Has somebody else opinion on this problem?

Because I still think that funlinkat() syscall has its usage.

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)