From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valerie Aurora Subject: Union mounts and fchown/fchmod/utimensat Date: Fri, 26 Mar 2010 18:45:34 -0400 Message-ID: <20100326224533.GB29874@shell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Viro , Erez Zadok , "J. R. Okajima" , Christoph Hellwig To: linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:16463 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754459Ab0CZWpy (ORCPT ); Fri, 26 Mar 2010 18:45:54 -0400 Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: In the current union mount design, files that will be modified are copied up from the lower layer file system to the top layer at open() time. However, there are three cases in which metadata can be modified through a file descriptor opened O_RDONLY: fchown(), fchmod(), and utimensat(). Currently, we only copy up a file before it is open, never after. Implementing these system calls would require replacing the read-only open file descriptor from the lower file system with a new file descriptor from the topmost layer - in other words, a huge nasty hack. 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? -VAL