Thread (8 messages) flat view 8 messages, 5 authors, 2017-01-31

Re: utimensat EACCES vs. EPERM in 4.8+

From: Carlos O'Donell <hidden>
Date: 2017-01-17 04:50:47
Also in: linux-fsdevel, ltp

On 01/16/2017 07:04 PM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api + Dave Chinner]
Summary of the above list: there's a nontrivial risk that something in
userspace got broken. (And just because we didn't hear about it yet
doesn't mean it didn't happen; sometimes these reports only arrive
many months or even years later.)

So, (1) I'm struggling to see the rationale for this change (I don't
think "consistency" is enough) and (2) if "consistency" is the
argument then (because the set of system calls in [1] are more
frequently used than those in [2]), there's a reasonable argument that
the change should have gone the other way: changing all IS_IMMUTABLE
cases to fail with EACCES.

Summary: I think there's an argument for reverting the kernel patch.
Completely agree.

Even if you go ahead with these changes, they really should go through
some kind of distro verification [1]. If I even contemplated such a change
in glibc I'd run it through 4-6 months of Fedora Rawhide builds just to
see what breaks before putting it out in a real release (and we do this
frequently for thread-related changes).

-- 
Cheers,
Carlos.

[1] "Usage of Fedora Rawhide" https://fedoraproject.org/wiki/Glibc
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help