Re: utimensat EACCES vs. EPERM in 4.8+

["Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>]

Hi Miklos,

On 01/17/2017 10:39 PM, Miklos Szeredi wrote:
> On Tue, Jan 17, 2017 at 8:57 AM, Cyril Hrubis <chrubis@suse.cz> wrote:
>> Hi!
>>>> Jan, thanks for spotting this.
>>>
>>> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
>>> with current documented behavior - few failures are expected on 4.8+.
>>
>> Actually credit goes to SUSE QAM that caught the change on kernel
>> update :-).
> 
> And while this makes for a nice discussion, it is almost completely
> irrelevant in real life, since the only thing broken by this change
> will be test suites (in other words immutable files are rare as hen's
> teeth).

While I agree that the chances of breakage may be quite small (though
I certainly won't be so bold as to assert that only test suites
will get broken), your comment misses the important metapoint:
changes like this should not just be getting waved through the gate
without some analysis along the lines of what I did. "Consistency"
and an (incorrect) assertion that "In most cases, EPERM is returned
on immutable inode" just don't cut it, when it comes to making
changes of this sort.

> If you find that this change actually breaks something other than a
> test suite, then yes, please lets revert it.  

No. That is not a strategy. I already said it, but I'll say it again:
sometimes these reports only arrive many months or even years later.
And then we can end up with fiascoes such as F_SETOWN/F_SETOWN_EX.
(Essentially: F_SETOWN got subtly changed, and by the time people
realized the breakage had occurred it was *years* late. Too late to
revert... So, then we got F_SETOWN_EX to allow us what F_SETOWN
used to do. See fcntl(2).)

> Otherwise there's not
> much point (distros can revert it for themselves if they want be
> paranoid).

Also not a strategy; distros don't want to carry such junk
patches.

All of this said, I still don't know whether reverting the patch
is warranted...

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/