Ondřej Vašík <[EMAIL PROTECTED]> wrote:
> as reported in
> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/187315 by Aaron
> Toponce , chmod could display confusing messages when used for
> SGID/SUID/sticky bits without permissions to change them.
>
> e.g. with non-root sudoers user following scenario
> mkdir tmp;sudo chown .root tmp;ls -ld tmp;chmod -v 2755 tmp;ls -ld tmp;
> would lead to:
> drwxrwxr-x 2 Reset root 4096 24. říj 17.33 tmp
> mode of `tmp' changed to 2755 (rwxr-sr-x)
> drwxr-xr-x 2 Reset root 4096 24. říj 17.33 tmp
>
> So user is informed that sticky bit was set even if it was not.
This is a good excuse to start the process.
Note this TODO item:
remove or adjust chown's --changes option, since it
can't always do what it currently says it does.
Almost from the beginning, I've wanted to remove support for
--changes (-c) from chmod, chown and chgrp. Note that the
original chcon implementation had that option, but I removed it as
part of the big SELinux-support-adding changes.
So, rather than trying to "fix" --changes, I'm leaning towards
starting the process to remove it altogether. From chmod,
chown, and chgrp.
This may seem extreme, until you realize that the option is inherently
inaccurate in some cases. And the only way it can be accurate is if
"<PROG> --changes ..." were to stat each file after operating on it.
I.e., the current implementations, even with your patch,
can still produce misleading output.
FYI, it's telling to see that when I ripped out all support
for chmod's --verbose and --changes options ("just to see"),
all tests still passed.
Of course, I wouldn't do that "for real". We'd have to first
deprecate the targeted options, making any use provoke a warning,
and then -- years later -- un-document and finally, remove them.
And I probably wouldn't even deprecate --verbose.
What do you think?
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
