From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Elsayed Subject: Re: [PATCH 0/6] File Sealing & memfd_create() Date: Thu, 10 Apr 2014 23:09:46 -0700 Message-ID: References: <1395256011-2423-1-git-send-email-dh.herrmann@gmail.com> <20140320153250.GC20618@thunk.org> <1397141388.16343.10@mail.messagingengine.com> <5346EDE8.2060004@amacapital.net> <1397159378.4434.1@mail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Return-path: Sender: owner-linux-mm@kvack.org To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fsdevel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org Colin Walters wrote: > On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski > wrote: >> >> >> COW links can do this already, I think. Of course, you'll have to >> use a >> filesystem that supports them. > > COW is nice if the filesystem supports them, but my userspace code > needs to be filesystem agnostic. Because of that, the design for > userspace simply doesn't allow arbitrary writes. > > Instead, I have to painfully audit every rpm %post/dpkg postinst type > script to ensure they break hardlinks, and furthermore only allow > executing scripts that are known to do so. > > But I think even in a btrfs world it'd still be useful to mark files as > content-immutable. If you create each tree as a subvolume and when it's complete put it in place with btrfs subvolume snapshot -r FOO_inprogress /ostree/repo/FOO, you get exactly that. You can even use the new(ish) btrfs out-of-band dedup functionality to deduplicate read-only snapshots safely. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Elsayed Subject: Re: [PATCH 0/6] File Sealing & memfd_create() Date: Thu, 10 Apr 2014 23:09:46 -0700 Message-ID: References: <1395256011-2423-1-git-send-email-dh.herrmann@gmail.com> <20140320153250.GC20618@thunk.org> <1397141388.16343.10@mail.messagingengine.com> <5346EDE8.2060004@amacapital.net> <1397159378.4434.1@mail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Cc: linux-kernel@vger.kernel.org,dri-devel@lists.freedesktop.org,linux-fsdevel@vger.kernel.org To: linux-mm@kvack.org Return-path: Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org Colin Walters wrote: > On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski > wrote: >> >> >> COW links can do this already, I think. Of course, you'll have to >> use a >> filesystem that supports them. > > COW is nice if the filesystem supports them, but my userspace code > needs to be filesystem agnostic. Because of that, the design for > userspace simply doesn't allow arbitrary writes. > > Instead, I have to painfully audit every rpm %post/dpkg postinst type > script to ensure they break hardlinks, and furthermore only allow > executing scripts that are known to do so. > > But I think even in a btrfs world it'd still be useful to mark files as > content-immutable. If you create each tree as a subvolume and when it's complete put it in place with btrfs subvolume snapshot -r FOO_inprogress /ostree/repo/FOO, you get exactly that. You can even use the new(ish) btrfs out-of-band dedup functionality to deduplicate read-only snapshots safely. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org