--=_courier-25595-1056534818-0001-2
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
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
--=_courier-25595-1056534818-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE++XCeq3909GIf5uoRApqRAJ9YmU33jWRi0cP2Ag35sWfrat/WbwCeOnwT
ae7xT+0FTcp9jURFPUPBvFM=
=KoiD
-----END PGP SIGNATURE-----
--=_courier-25595-1056534818-0001-2--