From: Arjan van de Ven <arjanv@redhat.com>
To: grendel@debian.org
Cc: Steve Lord <lord@sgi.com>, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [2.5.73-mm1 XFS] restrict_chown and quotas
Date: 25 Jun 2003 16:25:44 +0200 [thread overview]
Message-ID: <1056551143.5779.0.camel@laptop.fenrus.com> (raw)
In-Reply-To: <20030625134129.GG1745@thanes.org>
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
On Wed, 2003-06-25 at 15:41, Marek Habersack wrote:
> On Wed, Jun 25, 2003 at 07:51:43AM -0500, Steve Lord scribbled:
> [snip]
> > > For me both of the described situations seem to be a bug, but I might be
> > > unaware of the rationale behind the functionality. If this is supposed to be
> > > that way, maybe at least it would be better to default restrict_chown to
> > > enabled initially? The behavior with restrict_chown is totally different to
> > > what users/administrators are used to and, as shown in the debian package
> > > build case, it might cause problems in usual situations. Also the quota
> > > issue is likely to be an excellent tool for local DoS.
> > > So, am I wrong in thinking that it's a bug (or at least the quota part of
> > > it) or not?
> >
> > Sorry about this, the defaults for the systunes have been messed up
> > recently. This is supposed to be on by default, irix_sgid_inherit
> > is on, but should be off by default.
> >
> > You can switch the behavior with /proc/sys/fs/xfs/restrict_chown
> > and irix_sgid_inherit.
> Yep, that's what I did. I was just caught by surprise discovering the new
> behavior :) and it if it was to be the default, it would have created a big
> problem for distributions compatibility-wise.
>
> > You can also edit xfs_globals.c to switch the default at boot time.
> > We will switch it back in the next update to Linus.
> Great, that's good enough.
>
> > As for the quota operation, the normal chown situation is going
> > from root to another id, and in that case, you want the quota to
> > go to the end user.
another question is why is this a filesystem specific option and not a
generic option ?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-06-25 14:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-25 9:51 Marek Habersack
2003-06-25 12:51 ` Steve Lord
2003-06-25 13:41 ` Marek Habersack
2003-06-25 14:25 ` Arjan van de Ven [this message]
2003-06-25 14:35 ` Christoph Hellwig
2003-06-25 15:11 ` Steve Lord
2003-06-25 15:16 ` Christoph Hellwig
2003-06-25 15:25 ` Steve Lord
2003-06-26 2:00 ` jw schultz
2003-06-25 15:39 ` Marek Habersack
2003-06-25 15:56 ` Christoph Hellwig
2003-06-25 15:11 ` Valdis.Kletnieks
2003-06-25 15:46 ` Marek Habersack
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=1056551143.5779.0.camel@laptop.fenrus.com \
--to=arjanv@redhat.com \
--cc=grendel@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lord@sgi.com \
/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
all inboxes | Powered by JetHome®