Re: Race-free unlinking of directory entries

[Pali RohÃr]

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@xxxxxxxxx

Attachment: signature.asc
Description: PGP signature