public inbox for linux-security-module@vger.kernel.org
 help / color / mirror / Atom feed
From: "Mickaël Salaün" <mic@digikod.net>
To: "Günther Noack" <gnoack@google.com>
Cc: linux-security-module@vger.kernel.org
Subject: Re: [PATCH] landlock: Document fallocate(2) as another truncation corner case
Date: Thu, 2 Apr 2026 20:16:27 +0200	[thread overview]
Message-ID: <20260402.rai0Iegh2ohy@digikod.net> (raw)
In-Reply-To: <ac1SP3cGuEeIZFmM@google.com>

On Wed, Apr 01, 2026 at 07:13:35PM +0200, Günther Noack wrote:
> On Wed, Apr 01, 2026 at 06:30:28PM +0200, Mickaël Salaün wrote:
> > On Wed, Apr 01, 2026 at 05:09:10PM +0200, Günther Noack wrote:
> > > Reinforce the already stated policy that LANDLOCK_ACCESS_FS_TRUNCATE should
> > > always go hand in hand with LANDLOCK_ACCESS_FS_WRITE_FILE, as their
> > > meanings and enforcement overlap in counterintuitive ways.
> > > 
> > > On many common file systems, fallocate(2) offers a way to shorten files as
> > > long as the file is opened for writing, side-stepping the
> > > LANDLOCK_ACCESS_FS_TRUNCATE right.
> > > 
> > > Assisted-by: Gemini-CLI:gemini-3.1
> > > Signed-off-by: Günther Noack <gnoack@google.com>
> > > ---
> > >  Documentation/userspace-api/landlock.rst | 8 ++++++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst
> > > index 7f86d7a37dc2..d5691ec136cc 100644
> > > --- a/Documentation/userspace-api/landlock.rst
> > > +++ b/Documentation/userspace-api/landlock.rst
> > > @@ -378,8 +378,8 @@ Truncating files
> > >  
> > >  The operations covered by ``LANDLOCK_ACCESS_FS_WRITE_FILE`` and
> > >  ``LANDLOCK_ACCESS_FS_TRUNCATE`` both change the contents of a file and sometimes
> > > -overlap in non-intuitive ways.  It is recommended to always specify both of
> > > -these together.
> > > +overlap in non-intuitive ways.  It is strongly recommended to always specify
> > > +both of these together (either granting both, or granting none).
> > >  
> > >  A particularly surprising example is :manpage:`creat(2)`.  The name suggests
> > >  that this system call requires the rights to create and write files.  However,
> > > @@ -391,6 +391,10 @@ It should also be noted that truncating files does not require the
> > >  system call, this can also be done through :manpage:`open(2)` with the flags
> > >  ``O_RDONLY | O_TRUNC``.
> > >  
> > > +At the same time, on some filesystems, :manpage:`fallocate(2)` offers a way to
> > > +shorten file contents with ``FALLOC_FL_COLLAPSE_RANGE`` when the file is opened
> > > +for writing, sidestepping the ``LANDLOCK_ACCESS_FS_TRUNCATE`` right.
> > 
> > Interesting, which filesystems?  Shouldn't it be fixed in the code
> > instead?
> 
> It works on ext4, and I also see mentions of FALLOC_FL_COLLAPSE_RANGE
> in XFS, F2FS, SMB and NTFS3.
> 
> I should mention, it is not *exactly* the same as a truncation, but
> you can remove a chunk of the file from the middle, which also leads
> to a shorter file.  For example, assuming a block size of 1024:
> 
>   1. Make a file with 2*1024 bytes: 1024*'A', then 1024*'B'
>   2. fallocate(collapse range, 0, 1024)
> 
> Resulting file is 1024*'B', and the file is shortened to 1024 bytes.
> 
> So this is not *exactly* a truncation.  (The man page says that an
> attempt to remove the end of a file results in EINVAL, so you have to
> take it from the middle, and it needs to align with block boundaries.)
> 
> But it's quite similar, also shortens the file, and it does not
> require the Landlock truncation access right.
> 
> I agree, another way would potentially be to call the LSM ftruncate
> hook.  I suspect this would stay compatible with other LSMs, because
> the LSM ftruncate hook is a relatively recent addition (but have not
> checked in detail).
> 
> The implementation of fallocate is vfs_fallocate() in fs/open.c - I
> only had a tentative look now; it checks that the file->f_mode is open
> for writing and calls security_file_permission() with MAY_WRITE.
> 
> I always saw LANDLOCK_ACCESS_FS_WRITE_FILE and
> LANDLOCK_ACCESS_FS_TRUNCATE as rights that should always go together,
> so I suspect that it does not make a big difference in practice, and
> that is why I am suggesting to just document it more clearly for now.

OK, I agree, I'll take this patch. Thanks!

> 
> —Günther
> 

      reply	other threads:[~2026-04-02 18:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-01 15:09 [PATCH] landlock: Document fallocate(2) as another truncation corner case Günther Noack
2026-04-01 16:30 ` Mickaël Salaün
2026-04-01 17:13   ` Günther Noack
2026-04-02 18:16     ` Mickaël Salaün [this message]

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=20260402.rai0Iegh2ohy@digikod.net \
    --to=mic@digikod.net \
    --cc=gnoack@google.com \
    --cc=linux-security-module@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