On 10.01.2017 21:11, Amir Goldstein wrote:
On Tue, Jan 10, 2017 at 6:34 PM, Konstantin Khlebnikov
<khlebni...@yandex-team.ru> wrote:
On 10.01.2017 18:57, Miklos Szeredi wrote:
On Tue, Jan 10, 2017 at 3:46 PM, Vivek Goyal <vgo...@redhat.com> wrote:
On Tue, Jan 10, 2017 at 02:26:48PM +0300, Konstantin Khlebnikov wrote:
If overlay was mounted by root then quota set for upper layer does not work
because overlay now always use mounter's credentials for operations.
This patch adds second copy of credentials without CAP_SYS_RESOURCE and
use it if current task doesn't have this capability in mounter's user-ns.
This affects creation new files, whiteouts, and copy-up operations.
Now quota limits are ignored only if both mounter and current task have
capability CAP_SYS_RESOURCE in root user namespace.
This makes sense to me. I too would like quota to take effect for
containers on overlay.
At first sight I hated this patch. It breaks the nice concept that
underlying filesystems are just storage for the overlay and don't care
about caller's privileges (as a block device wouldn't care about
caller's privileges when allocating space).
However I don't see a good way around this, so...
Another solution: just always drop CAP_SYS_RESOURCE from capabilities.
That sounds like a better (and simpler) solution.
Let overlayfs support mount options noquota|quota (default configurable
from Kconfig and module param) and 'quota' means drop CAP_SYS_RESOURCE.
Too complicated for me. Let's drop it unconditionally. See v2 patch.
Looks like this also has effect on reserving space in ext4, not sure
what that entails.
Yes, CAP_SYS_RESOURCE allows to use reserved space and inodes.
That's really not good. It's beyond disobeying user quotas, because
file system may get to unrecoverable state when corruption is detected
and already filled the root reserved space.
Amir.
--
Konstantin
