Ondřej Vašík <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> 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. >> 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. >> 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? > > Throwing out "--changes" should be ok, if user wants to be informed, he > can parse verbose output easily and common case is to use it without > verbose mode at all. Anyway --verbose output is affected by this "issue" > as well, so I would prefer to > 1) depricate --changes option as it could be substituted by --verbose > and grep > 2) fix the verbose output to show correct output in every case where it > is possible. E.g. if the stat fails, it should inform the user that the > mode/owner/whatever is unknown. E.g. SGID bit case or stat failed is the > thing where user should be informed in verbose mode about something > unusual.
Actually, I was thinking of making --verbose output *less* informative, so that it can be truthful, albeit less informative, without adding extra stat/lstat calls. Sort of like chcon, which says simply changing security context of FILE While I do see the down-side of doing that, it seems better to print less information, with a guarantee of no lies, than to print usually-true messages along with the occasional untruth. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils