mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steve Lord <lord@sgi.com>
To: grendel@debian.org
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [2.5.73-mm1 XFS] restrict_chown and quotas
Date: 25 Jun 2003 07:51:43 -0500	[thread overview]
Message-ID: <1056545505.1170.19.camel@laptop.americas.sgi.com> (raw)
In-Reply-To: <20030625095126.GD1745@thanes.org>

On Wed, 2003-06-25 at 04:51, Marek Habersack wrote:
> Hello,
> 
>   I've discovered yesterday, by sheer accident (building a deb package which
> process uses fakeroot) that the XFS in 2.5.73-mm1 (and probably in vanilla
> 2.5.73 as well) implements the restrict_chown policy and syscall while
> defaulting to the relaxed chown behavior. That way a user can give away
> their files/directories while retaining full control in the sense that the
> owner of the containing directory can remove the chowned entries. Removing
> the entries not owned/chowned by you but living in a directory owned by you is also
> possible (both with restricted_chown in effect and when it's not effective)
> on XFS filesystems.
>   It also seems (although I haven't tested it, just looked at the source code)
> that when one chowns a file/directory to another uid:gid when restrict_chown
> is in effect, the quota is changed as well - it gets transferred to the
> target uid:gid.
>   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.

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.

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. In the non restricted chown case, if the
quota remained with the original user, how do you decide which
user's quota to remove the file space from when it is deleted,
once a file is chowned, there is no record of who it was created
as. The quota has to stick with the uid of the file.

Steve



  reply	other threads:[~2003-06-25 12:37 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 [this message]
2003-06-25 13:41   ` Marek Habersack
2003-06-25 14:25     ` Arjan van de Ven
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=1056545505.1170.19.camel@laptop.americas.sgi.com \
    --to=lord@sgi.com \
    --cc=grendel@debian.org \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®