linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Colin Walters <walters@verbum.org>
To: Linux-Fsdevel <linux-fsdevel@vger.kernel.org>
Subject: immutable files via O_OBJECT
Date: Fri, 09 May 2014 10:10:22 +0000	[thread overview]
Message-ID: <1399630462.17314.3@mail.messagingengine.com> (raw)

Hi,

I'm the author of https://live.gnome.org/Projects/OSTree which is a new 
general purpose update system for Linux-based operating systems.

Basically it does updates by creating a new hardlink farm chroot. 
(There's nothing really new about this, OSTree is just a polished 
version of it with a new twist or two)

Now present, I have a read-only bind mount over /usr. What I'd really 
like is something like the existing S_IMMUTABLE bit except with the 
ability to make hardlinks.  Also unlike S_IMMUTABLE I don't want it to 
be removable at all.

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.

(It would also be nice to have a way to make xattrs immutable, but I 
see that as a separate thing)

I can imagine that beyond the security aspect, filesystems could make 
some interesting optimizations if userspace opted out of the ability to 
mutate files post-creation.

Both OSTree and git could use it (git for loose objects).

There's been stuff somewhat related to this in the past, like 
linux-vserver was carrying a hack to do CoW hardlinks. But I think it's 
really better to just disallow mutation and force userspace to break 
hardlinks.

If you guys give me this flag, I'll make use of it in userspace pretty 
much right away =)


             reply	other threads:[~2014-05-09 10:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 10:10 Colin Walters [this message]
2014-05-09 14:32 ` immutable files via O_OBJECT Theodore Ts'o
2014-05-09 15:12   ` Colin Walters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1399630462.17314.3@mail.messagingengine.com \
    --to=walters@verbum.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).