Re: [2.5.73-mm1 XFS] restrict_chown and quotas

[Marek Habersack <grendel@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 2886 bytes --]

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. 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.
Right, but that way you're granting a non-privileged user the superuser
rights without proper authentication/authorization. I see use for
non-restricted chown in tight groups of cooperating people, but in general
it looks to be more a hazard than an advantage. I might be wrong, though...
And what about the right to partially control the file whose ownership you
transferred to another user? Currently it is possible to chmod a file to
0600 (or directory to 0700), chown it to root and then remove it - but you
cannot write to it not even open it. Also, an administrator might expect
that a file created with the root rights in the user's directory will remain
untouchable/unreadable/inmutable to the user, but this is not so - the user
can remove any files created by root whether or not restricted_chown is in
effect. That might be quite a nightmare for the admins. Or at the very least
it's inconsistent with other filesystems. 
Anyhow, maybe I'm completely wrong on the above topics, but it does seem
like a security problem in general..

regards,

marek


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]