linux-kernel - Re: truncate on MAP_SHARED files in ramfs filesystems on no-mmu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <24005.1247134018@redhat.com>
Date:	Thu, 09 Jul 2009 11:06:58 +0100
From:	David Howells <dhowells@...hat.com>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	dhowells@...hat.com,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: truncate on MAP_SHARED files in ramfs filesystems on no-mmu

Mike Frysinger <vapier.adi@...il.com> wrote:

> reviewing LTP tests shows mmap09 failing.  this test creates a file of
> a certain length, opens it and creates a shared mapping, and then
> tries various truncate tests:
> truncate to a smaller size
> truncate to a larger size
> truncate to size 0
> 
> the first and last fail on no-mmu due to
> file-nommu.c:ramfs_nommu_resize() rejecting attempts to shrink on a
> shared mapping:

Yes.  That's exactly right.

> my question is why?  if an application maps a fd with MAP_SHARED,
> truncates it, and then it or someone else who has that fd mapped tries
> to access the now-invalid tail end, that is a bug in the application.
> i dont see why we should be protecting users here from their own buggy
> code ?

This is protecting the kernel as much as the user.  There's no MMU to enforce
denial of access on the pages that truncate returns to the system.

This doesn't only protect the process with a mapping on that file against its
own truncate, but also other processes that have made mappings against that
file.

Whilst you can argue it either way, you need a better reason to change this
than it causes some LTP failures.  You cannot expect all the MM-related LTP
tests to work against a NOMMU system.

Doing it this way also makes things simpler in the kernel and makes the system
more robust.

If a process shared mmaps a file and then wants to truncate it, it can always
munmap the excess first.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/