What do you mean "extending SGID priveleges"? The only consequence I can see
is if the file was not world executable to start with, they are now able to
execute it, and it will run SGID. That doesn't seem unreasonable to me. Can
you give an example where this would not be what was wanted?
> 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.
If you have an SUID program that is not world-executable and you change the
group, surely the whole point would be to allow a different set of users to
execute the SUID program?
> 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.
I see what you mean, but I don't think it is a problem. You should write a
patch to fix the comments so it matches the code then. The patch by Greg
fixes the code so it matches the comments.
> > - 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.
It does chgrp files for owners not in the group. What is wrong with that (and
what do you mean about it being documented?)
> I don't
> know what SUID does for directories,
AFAIK, SUID does nothing for directories. Anyone else know?
> 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!).
You need to be in the group to be able to turn on SGID.
> 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.
What do you mean the "safe" version of SGID on a directory? There is no
amplification of privileges involved here that I can see. Can you give an
example of how someone's privileges can be amplified? Creating files
group-owned by the group-owner of the directory is the whole point of SGID
directories. If you don't want just anyone doing that then you don't give
world-write permission to the directory.
Regards,
-- Geoffrey D. Bennett (geoffrey@netcraft.com.au) Computer Systems Manager, NetCraft Australia http://www.netcraft.com.au/geoffrey/ Red Hat Linux Resellers: http://www.netcraft.com.au/redhat/