Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

[Jim Meyering]

Ondřej Vašík <address@hidden> wrote:
> Jim Meyering wrote:
>> Ondřej Vašík <address@hidden> 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.