From: Sargun Dhillon <sargun@sargun.me>
To: dsterba@suse.cz, Sargun Dhillon <sargun@sargun.me>,
Adam Borowski <kilobyte@angband.pl>,
BTRFS ML <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs: allow processes with cap_sys_resource to exceed quota
Date: Fri, 5 May 2017 11:25:36 -0700 [thread overview]
Message-ID: <CAMp4zn9BmNqkmToxVSBF9FsUTBoHzr2CLSXPBjADS-ZTZqn_fw@mail.gmail.com> (raw)
In-Reply-To: <20170505182247.GL10575@twin.jikos.cz>
If you see my follow-on patch, it allows disabling the quota limit for
folks with cap_sys_resource per filesystem. I don't want to have any
process to be able to turn off quota limits, but just the process that
is the logrotator (and has the proper capabilities). Unfortunately,
most folks don't lock down their capabilities, so I agree, making it
blindly based on capabilities seems like a poor idea.
On Fri, May 5, 2017 at 11:22 AM, David Sterba <dsterba@suse.cz> wrote:
> On Fri, Apr 21, 2017 at 07:27:23AM -0500, Sargun Dhillon wrote:
>> What do you think about putting this behaviour behind a sysctl? Seems
>> better than to start introducing a new mechanism of marking tasks?
>
> Technically it's easy to add own btrfs-specific ioctl, temporarily
> turning off quota limits, but I'm still not sure about all the
> consequences as this would apply to the whole system, no? The
> capabilities are per process, much more fine grained. I don't have other
> ideas how to address the problem though.
prev parent reply other threads:[~2017-05-05 18:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-21 10:09 [PATCH] btrfs: allow processes with cap_sys_resource to exceed quota Sargun Dhillon
2017-04-21 10:34 ` Sargun Dhillon
2017-04-21 11:05 ` Adam Borowski
2017-04-21 12:27 ` Sargun Dhillon
2017-05-05 18:22 ` David Sterba
2017-05-05 18:25 ` Sargun Dhillon [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=CAMp4zn9BmNqkmToxVSBF9FsUTBoHzr2CLSXPBjADS-ZTZqn_fw@mail.gmail.com \
--to=sargun@sargun.me \
--cc=dsterba@suse.cz \
--cc=kilobyte@angband.pl \
--cc=linux-btrfs@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;
as well as URLs for NNTP newsgroup(s).