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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 19 Jul 2019 14:04:18 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Ian Malone <ibmalone@...il.com>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: ext4 reserved blocks not enforced?

On Thu, Jul 18, 2019 at 04:26:19PM +0100, Ian Malone wrote:
> Recently we extended a ~1.9TB filesystem by 20GB, however afterwards
> df reported 0 available bytes. The LV had been increased and running
> resize2fs reported that the fs was already the full size of the
> device. tune2fs showed fewer free blocks than reserved blocks. Despite
> this, normal users could create files on the filesystem (via nfs)

It's the "via NFS" which is the issue.  The problem is that model with
NFS is that access checks are done on the client side, and the NFS
client doesn't know about ext4's reserved block policy (nor does the
NFS client have a good way of knowing how blocks are reserved, or,
without constantly requesting the free space via repeated NFS queries,
how many free blocks are availble on the server).

On the NFS server side, the server has no way of knowing whether or
not "root" was issuing the write.  The NFS server could know whether
or not the "root squash" flag is set, and pass that to ext4, but
that's not currently being done.

						- Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ