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
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
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
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 ?
On Wed, Jun 25, 2003 at 04:25:44PM +0200, Arjan van de Ven wrote:
> 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.
On Wed, 25 Jun 2003 15:41:29 +0200, Marek Habersack said:
> 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.
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, 2003-06-25 at 09:35, Christoph Hellwig wrote:
> On Wed, Jun 25, 2003 at 04:25:44PM +0200, Arjan van de Ven wrote:
> > 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
On Wed, Jun 25, 2003 at 10:11:40AM -0500, Steve Lord wrote:
> 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
On Wed, 2003-06-25 at 10:16, Christoph Hellwig wrote:
> On Wed, Jun 25, 2003 at 10:11:40AM -0500, Steve Lord wrote:
> > 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
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
On Wed, Jun 25, 2003 at 04:16:27PM +0100, Christoph Hellwig scribbled:
[snip]
> > 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
This being clear, maybe it should be a compile-time option in XFS? Or
would that be unacceptable?
marek
On Wed, Jun 25, 2003 at 11:11:51AM -0400, [email protected] scribbled:
[snip]
> > 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.
>
> 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
On Wed, Jun 25, 2003 at 05:39:43PM +0200, Marek Habersack wrote:
> This being clear, maybe it should be a compile-time option in XFS? Or
> would that be unacceptable?
Yes. It's also utterly pointless.
On Wed, Jun 25, 2003 at 10:25:26AM -0500, Steve Lord wrote:
> On Wed, 2003-06-25 at 10:16, Christoph Hellwig wrote:
> > On Wed, Jun 25, 2003 at 10:11:40AM -0500, Steve Lord wrote:
> > > 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
>
> 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.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt