linux-kernel - Re: [linux-cifs-client] Re: unlink behavior when file is open by other process

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 17 Oct 2008 15:52:46 -0400
From:	jim owens <jowens@...com>
To:	Jeff Layton <jlayton@...hat.com>
CC:	Steve French <smfrench@...il.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	"linux-cifs-client@...ts.samba.org" 
	<linux-cifs-client@...ts.samba.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [linux-cifs-client] Re: unlink behavior when file is open by
 other process

Jeff Layton wrote:

> Sure, I'm not disputing whether returning an error on open is right or
> wrong. The problem is that it's not expected. We've just unlinked the
> filename and returned success -- there is *no* reason that the create
> should fail here. An application programmer will (rightfully) consider
> this a bug.

I agree that failing the unlink if you can not do it is
"the right thing to do"... but unless you have some magic
to prevent anyone else from creating the file between that
unlink and the create then in fact there is a reason the
application can see the create fail after unlink succeeds :)
--
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/