From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: New reflink(2) syscall Date: Tue, 5 May 2009 23:45:52 +0100 Message-ID: <20090505224552.GH7574@shareable.org> References: <1241458669.3023.203.camel@localhost.localdomain> <20090504180855.GE31249@mail.oracle.com> <1241465446.3023.228.camel@localhost.localdomain> <20090504210356.GA25313@mail.oracle.com> <20090504231334.GA17486@mit.edu> <20090505164700.GB7835@mail.oracle.com> <1241542618.7244.76.camel@think.oraclecorp.com> <20090505171331.GG7835@mail.oracle.com> <20090505173423.GH17486@mit.edu> <1241545451.3023.341.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Theodore Tso , Chris Mason , James Morris , lsm , linux-fsdevel@vger.kernel.org To: Stephen Smalley Return-path: Content-Disposition: inline In-Reply-To: <1241545451.3023.341.camel@localhost.localdomain> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Stephen Smalley wrote: > Not arguing against this, but just to note: the security model will > differ depending on these flags, as the link-like case doesn't require > the caller to have read access to the file (the data is no more > accessible than it was before) One security difference between reflink() and link() when linking to _other_ user's files is they can tell if you suddenly got a link to their file, from their i_nlink. They can be suspicious and maybe overwrite the file in place, truncate it or something, and look around for the link you created in a secret place in your /home. But they can't see if you got a reflink to their file. Even though you can't read the file if you couldn't read it before, you now have a link to it which might preserve data they don't want to be preserved. So reflink() should, perhaps, be more restricted than link(). -- Jamie