Messages in this thread | | | Date | Wed, 25 Jun 2003 15:41:29 +0200 | From | Marek Habersack <> | Subject | Re: [2.5.73-mm1 XFS] restrict_chown and quotas |
| |
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
[unhandled content-type:application/pgp-signature] | |