From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: immutable files via O_OBJECT Date: Fri, 9 May 2014 10:32:45 -0400 Message-ID: <20140509143245.GA15523@thunk.org> References: <1399630462.17314.3@mail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linux-Fsdevel To: Colin Walters Return-path: Received: from imap.thunk.org ([74.207.234.97]:58687 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753367AbaEIOcs (ORCPT ); Fri, 9 May 2014 10:32:48 -0400 Content-Disposition: inline In-Reply-To: <1399630462.17314.3@mail.messagingengine.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, May 09, 2014 at 10:10:22AM +0000, Colin Walters wrote: > > And the more I thought about it, the more I realized what would be neat is a > new open flag "O_OBJECT". What this would do is disallow any further changes > to content after the file has been close()d or so. What's the security properties that this would buy you over simply doing something like this? fchmod(fd, 0444); Sure, root (or the owner) could change the always change the permissions on the file --- but root can always modify the file by opening the block device directly using a tool like debugfs. So if you need to guarantee that the object hasn't changed, you're going to have to you a cryptographic checksum, or such as what git does. I suppose the one benefit is that you could have a file which is owned by some uid other than root, and still have some form of immutability guarantees, which might be useful if you need the uid for (a) quota purposes, (b) setuid/setgid purposes, and (c) so that a non-root user can create one of these objects. But in order to do this, we would have to plumb through glibc, VFS, and low-level file system changes for a non-portable feature that would only be useful in Linux systems. Is it really worth it? - Ted