restrict_chown and quotas
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?
regards,
marek
Quoted 16 lines · Marek Habersack
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 therestrict_chownpolicy 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 withrestricted_chownin 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 whenrestrict_chownis 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
Quoted 8 lines
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_chownto enabled initially? The behavior withrestrict_chownis 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
On Wed, Jun 25, 2003 at 07:51:43AM -0500, Steve Lord scribbled:
[snip]
Quoted 10 lines
Quoted 9 lines
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 defaultrestrict_chownto enabled initially? The behavior withrestrict_chownis 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?
Quoted 6 lines
Sorry about this, the defaults for the systunes have been messed up recently. This is supposed to be on by default,
irix_sgid_inheritis on, but should be off by default.You can switch the behavior with
/proc/sys/fs/xfs/restrict_chownandirix_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.
Quoted 2 lines
You can also edit
xfs_globals.cto switch the default at boot time. We will switch it back in the next update to Linus.
Great, that's good enough.
Quoted 7 lines
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
Quoted 18 lines · Marek Habersack
On Wed, Jun 25, 2003 at 07:51:43AM -0500, Steve Lord scribbled:
[snip]Quoted 10 lines
Quoted 9 lines
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 defaultrestrict_chownto enabled initially? The behavior withrestrict_chownis 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?Quoted 6 lines
Sorry about this, the defaults for the systunes have been messed up recently. This is supposed to be on by default,
irix_sgid_inheritis on, but should be off by default.You can switch the behavior with
/proc/sys/fs/xfs/restrict_chownandirix_sgid_inherit.
Quoted 11 lines
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.
Quoted 2 lines
You can also edit
xfs_globals.cto switch the default at boot time. We will switch it back in the next update to Linus.Great, that's good enough.
Quoted 3 lines
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 ?
Quoted 2 lines · Arjan van de Ven
another question is why is this a filesystem specific option and not a generic option ?
Heh, I wonder the same when this was implemented the first time.
It should probably move to VFS.
Quoted 7 lines · Christoph Hellwig
Quoted 2 lines · Arjan van de Ven
another question is why is this a filesystem specific option and not a generic option ?
Heh, I wonder the same when this was implemented the first time.
It should probably move to VFS.
This is all backwards compatibility with folks expecting Irix behavior, and I think on Irix it is even a backwards compatibility thing. If we were not having a major power outage at work right now I could look at Irix and confirm this. Imposing different semantics on the rest of the filesystems did not seem like the right thing to do.
Steve
Quoted 5 lines · Steve Lord
This is all backwards compatibility with folks expecting Irix behavior, and I think on Irix it is even a backwards compatibility thing. If we were not having a major power outage at work right now I could look at Irix and confirm this. Imposing different semantics on the rest of the filesystems did not seem like the right thing to do.
Actually there's a posix option group for finding out exactly that, (see http://people.redhat.com/drepper/posix-option-groups.html#CHOWN_RESTRICTED)
but yeah it might be more of a legacy thing.
Adding a common sysctl for this would allow glibc to properly implement patchconf(..., _PC_CHOWN_RESTRICTED), but it seems SuSv2/3 sais it must be always defined:
http://www.opengroup.org/onlinepubs/007908799/xsh/chown.html
Quoted 11 lines · Christoph Hellwig
Quoted 5 lines · Steve Lord
This is all backwards compatibility with folks expecting Irix behavior, and I think on Irix it is even a backwards compatibility thing. If we were not having a major power outage at work right now I could look at Irix and confirm this. Imposing different semantics on the rest of the filesystems did not seem like the right thing to do.
Actually there's a posix option group for finding out exactly that, (see http://people.redhat.com/drepper/posix-option-groups.html#CHOWN_RESTRICTED)
but yeah it might be more of a legacy thing.
Quoted 5 lines
Adding a common sysctl for this would allow glibc to properly implement
patchconf(..., _PC_CHOWN_RESTRICTED), but it seems SuSv2/3 sais it must be always defined:http://www.opengroup.org/onlinepubs/007908799/xsh/chown.html
Thanks, I also found out that the unrestricted chown behavior is the way AT&T system V did it originally. I vote for this being a legacy thing.
Steve
Quoted 16 lines · Steve Lord
Quoted 15 lines · Christoph Hellwig
Quoted 5 lines · Steve Lord
This is all backwards compatibility with folks expecting Irix behavior, and I think on Irix it is even a backwards compatibility thing. If we were not having a major power outage at work right now I could look at Irix and confirm this. Imposing different semantics on the rest of the filesystems did not seem like the right thing to do.
Actually there's a posix option group for finding out exactly that, (see http://people.redhat.com/drepper/posix-option-groups.html#CHOWN_RESTRICTED)
but yeah it might be more of a legacy thing.Adding a common sysctl for this would allow glibc to properly implement
patchconf(..., _PC_CHOWN_RESTRICTED), but it seems SuSv2/3 sais it must be always defined:
Quoted 5 lines
Thanks, I also found out that the unrestricted chown behavior is the way AT&T system V did it originally. I vote for this being a legacy thing.
That is correct. It had some utility when a process could only be a member of one group at a time and for giving files to someone else while keeping all others out. Chown was expected to disable s[ug]id bits. The value of an unrestricted chown is very small and will be eliminated by ACLs.
Quotas turned it into a security issue. With unrestricted
chown a user could chown large files to another (preferably unlimited) uid and avoid the limits and usage charges. It also allows one user to sabotage another by causing that user to go over quota on files he has no knowledge or control over. Quotas and unrestricted chown do not mix.
Signature · 5 lines
________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [email protected] Remember Cernan and Schmitt
On Wed, Jun 25, 2003 at 04:16:27PM +0100, Christoph Hellwig scribbled:
[snip]
Quoted 7 lines
Quoted 2 lines
at Irix and confirm this. Imposing different semantics on the rest of the filesystems did not seem like the right thing to do.
Actually there's a posix option group for finding out exactly that, (see http://people.redhat.com/drepper/posix-option-groups.html#CHOWN_RESTRICTED)
but yeah it might be more of a legacy thing.
Quoted 5 lines
Adding a common sysctl for this would allow glibc to properly implement
patchconf(..., _PC_CHOWN_RESTRICTED), but it seems SuSv2/3 sais it must be always defined:http://www.opengroup.org/onlinepubs/007908799/xsh/chown.html
This being clear, maybe it should be a compile-time option in XFS? Or would that be unacceptable?
marek
Quoted 2 lines · Marek Habersack
This being clear, maybe it should be a compile-time option in XFS? Or would that be unacceptable?
Yes. It's also utterly pointless.
Quoted 9 lines · Marek Habersack
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_chownis in effect. That might be quite a nightmare for the admins. Or at the very least it's inconsistent with other filesystems.
Maybe I'm low on caffeine and therefor misreading it, but isn't this just an example of "file rename/remove requires write permission on the *parent* dirctory, since that's what's being changed", which often surprises novice (and not-so-novice) sysadmins? See also the reason for the sticky bit on directories..
In any case, I didn't notice that any behavior (other than the 'chown giveaway') was different than other filesystems?
On Wed, Jun 25, 2003 at 11:11:51AM -0400, [email protected] scribbled:
[snip]
Quoted 11 lines
Quoted 3 lines
can remove any files created by root whether or not
restricted_chownis in effect. That might be quite a nightmare for the admins. Or at the very least it's inconsistent with other filesystems.Maybe I'm low on caffeine and therefor misreading it, but isn't this just an example of "file rename/remove requires write permission on the *parent* dirctory, since that's what's being changed", which often surprises novice (and not-so-novice) sysadmins? See also the reason for the sticky bit on directories..
In any case, I didn't notice that any behavior (other than the 'chown giveaway') was different than other filesystems?
You're right. It must have been me who was low on caffeine. Indeed, the only problems were the chown giveaway and the quota ownership transfer. Forget the blurb, sorry
marek