* 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
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
On Wed, Jan 22, 2020 at 01:55:57PM -0800, Paul Eggert wrote:
> On 1/22/20 7:08 AM, Florian Weimer wrote:
> >I think you misread what I wrote: lchmod*always* returns ENOSYS. Even
> >if the file is not a symbolic link. Likewise, fchmodat with
> >AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP.
>
>
On 1/22/20 7:08 AM, Florian Weimer wrote:
I think you misread what I wrote: lchmod*always* returns ENOSYS. Even
if the file is not a symbolic link. Likewise, fchmodat with
AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP.
That's too bad, because coreutils (and many other applications, I
* Rich Felker:
> On Wed, Jan 22, 2020 at 09:48:14PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> >> Hmm. The way I read the musl code, the O_PATH descriptor already
>> >> exists. At this point, you can just chmod the O_PATH descriptor, and
>> >> have the kernel report EOPNOTSUPP if the
* Rich Felker:
>> Hmm. The way I read the musl code, the O_PATH descriptor already
>> exists. At this point, you can just chmod the O_PATH descriptor, and
>> have the kernel report EOPNOTSUPP if the file system does not support
>> that.
>
> Oh, you mean the second one after it's already open?
On Wed, Jan 22, 2020 at 05:19:05PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote:
> >> >> * Rich Felker:
> >> >>
> >> >> > On Wed,
* Rich Felker:
> On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote:
>> >> * Rich Felker:
>> >>
>> >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote:
>> >> >> * Rich Felker:
On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote:
> >> >> * Rich Felker:
> >> >>
> >> >> >
On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > coreutils should be opting to use the system-provided lchmod, which is
> > safe, and correctly handling error returns (silently treating
> > EOPNOTSUPP as success) rather than as hard errors.
>
> glibc's
On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> > coreutils should be opting to use the system-provided lchmod, which is
> >> > safe, and correctly handling error
* Rich Felker:
> On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote:
>> >> * Rich Felker:
>> >>
>> >> > coreutils should be opting to use the system-provided lchmod, which is
>> >> > safe, and
* Rich Felker:
> On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > coreutils should be opting to use the system-provided lchmod, which is
>> > safe, and correctly handling error returns (silently treating
>> > EOPNOTSUPP as success) rather than as hard
* Rich Felker:
> coreutils should be opting to use the system-provided lchmod, which is
> safe, and correctly handling error returns (silently treating
> EOPNOTSUPP as success) rather than as hard errors.
glibc's lchmod always returns ENOSYS (except on Hurd). I don't know how
lchmod is used in
17 matches
Mail list logo
