From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. R. Okajima" Subject: Re: Union mounts and fchown/fchmod/utimensat Date: Sun, 28 Mar 2010 00:43:23 +0900 Message-ID: <23818.1269704603@jrobl> References: <20100326224533.GB29874@shell> Cc: linux-fsdevel@vger.kernel.org, Alexander Viro , Erez Zadok , Christoph Hellwig To: Valerie Aurora Return-path: Received: from mtoichi13.ns.itscom.net ([219.110.2.183]:58828 "EHLO mtoichi13.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753558Ab0C0PoP (ORCPT ); Sat, 27 Mar 2010 11:44:15 -0400 In-Reply-To: <20100326224533.GB29874@shell> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Valerie Aurora: > My question: How often do applications actually attempt fchown(), > fchmod(), or utimensat() on an O_RDONLY file descriptor? Would it > break a lot of applications if a union mount file returned EBADF or > EPERM in this case? Unfortunately I don't know how often it is. But I am afraid it will be insufficient even if you implement the error. Do you remember the sample case I've written before? For instance, fd1 = open(path, O_RDONLY); fd2 = open(path, O_RDWR); fchmod(fd2); fstat(fd1, &st); In this case, fchmod will not return the error because fd2 is opened for write and the file would be copied-up. And the next fstat for fd1 will return a bogus info since fd1 still refers the file on the lower layer. Regardless fchmod() is issued by the same process or different one, fstat() lies. This is the same scenario I wrote before essentially (Jul 2009). Also we should take care of the file-locking. The copyup by UnionMount will break fcntl(F_SETLK) easily in the same scenario. But I am not sure how many applications depend upon file lock and UnionMount copyup affect.