lchmod on Linux

lchmod on Linux

[Tomasz Sterna]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

I think there is an issue with musl providing lchmod() implementation
on Linux.

It simply proxies to fchmodat(), but as you cannot change mod for
symlink on Linux it fails.

This gives trouble to libarchive's bsdtar implementation that detects
that platform provides lchmod, tries to use it while extracting
archives containing symlinks and fails... ;-(

For now I am just patching libarchive config.h to not use lchmod, but I
would rather see musl do the right thing. :-)


-- 
 /o__ Our missions are peaceful -- not for conquest. When we do battle, it
(_<^' is only because we have no choice.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: lchmod on Linux

[Rich Felker]

On Wed, Aug 26, 2015 at 09:12:30PM +0200, Tomasz Sterna wrote:
> I think there is an issue with musl providing lchmod() implementation
> on Linux.
> 
> It simply proxies to fchmodat(), but as you cannot change mod for
> symlink on Linux it fails.
> 
> This gives trouble to libarchive's bsdtar implementation that detects
> that platform provides lchmod, tries to use it while extracting
> archives containing symlinks and fails... ;-(
> 
> For now I am just patching libarchive config.h to not use lchmod, but I
> would rather see musl do the right thing. :-)

This issue (the useless lchmod) was raised once before, a long time
ago. But there's not really anything that can be done about it since
there are existing binaries referencing it.

But conceptually, the same issue would exist if libarchive were using
the fchmodat function rather than lchmod. So it seems to me that the
problem is not the existence of an operation that always-fails, but
rather libarchive's misinterpretation of the result. EOPNOTSUP is a
documented result for fchmodat, and generally programs should not
treat it as an error but should just ignore it. The same should
probably be done for lchmod.

Rich

Re: lchmod on Linux

[Tomasz Sterna]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

Dnia 2015-08-26, śro o godzinie 15:49 -0400, Rich Felker pisze:
> This issue (the useless lchmod) was raised once before, a long time
> ago. But there's not really anything that can be done about it since
> there are existing binaries referencing it.

One thing could be always returning 0, as this is really a no-op on
Linux.


> But conceptually, the same issue would exist if libarchive were using
> the fchmodat function rather than lchmod.

Well... fchmodat is a different function and you might expect it
failing.
But since a platform _is_ providing lchmod one should not expect it to
return not-supported when used on a symlink.
It would give me a serious WTF reading a code that uses a platform
supported function and checking for not-supported error. ;-)


> EOPNOTSUP is a documented result for fchmodat, [...]

Is it a documented result for lchmod? (Google is no help here.)
(If yes, I will die a little and just move on ;-)


-- 
 /o__ Q: Why did the astrophysicist order three hamburgers?
(_<^' A: Because he was hungry.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: lchmod on Linux

[Laurent Bercot]

On 26/08/2015 23:09, Tomasz Sterna wrote:
> One thing could be always returning 0, as this is really a no-op on
> Linux.

  I tend to agree with that.
  https://www.freebsd.org/cgi/man.cgi?query=lchmod&sektion=2  does not
describe EOPNOTSUPP as a possible error code. Is there a reason not
to make lchmod return 0 when the underlying fchmodat returns
-1 EOPNOTSUPP?


>> EOPNOTSUP is a documented result for fchmodat, [...]
> Is it a documented result for lchmod? (Google is no help here.)

  Not according to the FreeBSD doc.
  The thing is, lchmod() is not POSIX, it's only BSD (I could find
doc for FreeBSD and MacOS X); the best behaviour is not to use it
at all. What libarchive should really do is to replace lchmod() with
fchmodat() and explicitly test for EOPNOTSUPP.

-- 
  Laurent

Re: lchmod on Linux

[Rich Felker]

On Thu, Aug 27, 2015 at 12:02:41AM +0200, Laurent Bercot wrote:
> On 26/08/2015 23:09, Tomasz Sterna wrote:
> >One thing could be always returning 0, as this is really a no-op on
> >Linux.
> 
>  I tend to agree with that.
>  https://www.freebsd.org/cgi/man.cgi?query=lchmod&sektion=2  does not
> describe EOPNOTSUPP as a possible error code. Is there a reason not
> to make lchmod return 0 when the underlying fchmodat returns
> -1 EOPNOTSUPP?

Conceptually I think it's wrong to return 0 when the operation wasn't
performed. There's also an argument to be made that lchmod should be
equivalent to the corresponding fchmodat call; if it were ever
standardized, it almost certainly would be. If there were a strong
compatibility benefit to be had by making it return 0 despite these
things, that would certainly be worth weighing in on, but I don't
think there is any such issue. There are very few users of lchown, and
IIRC the other ones we've found handle it fine already.

> >>EOPNOTSUP is a documented result for fchmodat, [...]
> >Is it a documented result for lchmod? (Google is no help here.)
> 
>  Not according to the FreeBSD doc.
>  The thing is, lchmod() is not POSIX, it's only BSD (I could find
> doc for FreeBSD and MacOS X); the best behaviour is not to use it
> at all. What libarchive should really do is to replace lchmod() with
> fchmodat() and explicitly test for EOPNOTSUPP.

I agree entirely with this. lchown should not be used at all if
fchmodat is supported, since the latter has standardized behavior you
can rely upon. Can we just propose a patch to libarchive to use
fchmodat when it exists and properly check for EOPNOTSUPP?

Rich