Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 26 Aug 2015 21:39:04 -0400
From: Rich Felker <>
Subject: Re: lchmod on Linux

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.
>  does not
> describe EOPNOTSUPP as a possible error code. Is there a reason not
> to make lchmod return 0 when the underlying fchmodat returns

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?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.