> The current behaviour is broken because:
> - it removes the SGID bit if you change the owner, and it removes the SUID bit
> if you change the group.
Once the owner changes (possibly to someone not in the group), you're extending
SGID priveleges to the new owner (who might not have had them before). That should
not happen silently or accidentally. Likewise, if you change the group from
"trusted" to "lusers", you're almost certainly granting the benefit of the SUID
bit to the "lusers" who didn't have it before.
The SUID and SGID bits offer amplification of priveleges to whoever can access
the file. You can't tell chown or chgrp "yes, I mean to extend SUID/SGID privs
to these new people", and without explicit direction a change in ownership
should not offer amplified priveleges in addition, on general principles and
because that's the domain of chmod. With appropriate ACL's, where there are
SUID and SGID bits for each entry in the list, it would be possible to extend
ownership without extending other privs as well; with the UN*X file privs model,
there's no way to not give those extra privs to the new parties without denying
them to everyone.
> - it removes SUID and SGID bits from directories if you change the owner or the
> group.
I know (roughly) what SGID on a directory does; I just hope that either it
doesn't chgrp files for owners not in the group, or that the fact that it does
gets documented somewhere where people can actually see it. I don't know what
SUID does for directories, but I have a creeping terror about it similar to my
fear about SGID (especially if J. Random luser could create a file in such a
directory with permissions 07777!). But while the "safe" version of SGID on a
directory is relatively benign, it's still an amplification of priveleges,
and chgrp/chown changes which priveleges are extended.
Keith