On Tue, 2007-09-04 at 13:16 +0200, Tomas Ruprich wrote:
> Thanks for your reply and your time,
> i've reported it to centos bug tracking system. I will try it also on
> RHEL and if it occurs, i'll sent it also to the RH.
Good. If and when they close it, will you post in this thread so folks
know the result?
>
> > ISTM it's a bug and should be reported on both CentOS and RH tracking
> > systems. Two errors are apparent. One may be difficult to correct.
> >
> > As you originally discovered, the user ID is being change during
> > execution of the command to change a group. And it is using the ID from
> > the symbolic link owner, as you later noticed.
> >
> > The 2nd bug is a recursion into the original directory via the symbolic
> > link when dereference is not suppressed. IMO, recursion should not
> > occur, but I know from a programming background that it takes a little
> > foresight, thought and intense effort to avoid this sort of trap.
>
> I think, that dereferrence should occure (at least for my coreutils
> version); man chgrp:
> --dereference
> affect the referent of each symbolic link, rather than the symbolic
> link itself (this is the default)
I don't have an issue with dereference. My issue is is the recursion
into the directories that the symbolic link points to. This is a well
known potential problem when symbolic links point to places that have
symbolic links that (eventually) lead to the original symbolic link
again. Some packages (tar and find, IIRC and maybe some others) try to
avoid this trap in various ways.
IMO, all utilities that normally recurse in an environment wherein
looping via such mechanisms as symbolic links is possible should have
some basic checks trying to prevent eternal loops from occurring. I do
think the recursion, as reported in your OP, is a bug in that the
utility has not (apparently) made an attempt to prevent an interminable
loop.
But, that's my opinion from the days when we developers were expected to
do rigorous design and testing, rather than leaving it (intentionally)
to our users to suffer and report.
> <snip>
--
Bill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
