* Rich Felker:
> Note that in any case, musl's lchmod/fchmodat is not affected since it
> always refuses to change symlink modes; I did this because I was
> worried that chmod on the magic symlink in /proc might pass through
> not just to the symlink it refers to, but to the symlink target if one
On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote:
> On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> > * Paul Eggert:
> >
> > > On 1/22/20 2:05 PM, Rich Felker wrote:
> > >> I think we're approaching a consensus that glibc should fix this too,
> > >> so then it would
On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> * Paul Eggert:
>
> > On 1/22/20 2:05 PM, Rich Felker wrote:
> >> I think we're approaching a consensus that glibc should fix this too,
> >> so then it would just be gnulib matching the fix.
> >
> > I installed the attached patch to
* Paul Eggert:
> On 1/22/20 2:05 PM, Rich Felker wrote:
>> I think we're approaching a consensus that glibc should fix this too,
>> so then it would just be gnulib matching the fix.
>
> I installed the attached patch to Gnulib in preparation for the upcoming
> glibc fix. The patch causes
Hi Paul,
> similarly for lchmod on non-symlinks.
When I see a new autoconf test that activates an override, in order to
guarantee a certain documented behaviour, I like to add a unit test -
because in the past we several times had an override that would not
have passed the autoconf test either.
On 1/22/20 2:05 PM, Rich Felker wrote:
I think we're approaching a consensus that glibc should fix this too,
so then it would just be gnulib matching the fix.
I installed the attached patch to Gnulib in preparation for the upcoming
glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW
