From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id a4825a0b for ; Wed, 12 Feb 2020 19:08:03 +0000 (UTC) Received: (qmail 28020 invoked by uid 550); 12 Feb 2020 19:08:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27998 invoked from network); 12 Feb 2020 19:08:01 -0000 Date: Wed, 12 Feb 2020 14:07:42 -0500 From: Rich Felker To: Florian Weimer Cc: Paul Eggert , Florian Weimer , Gnulib bugs , musl@lists.openwall.com, 39236@debbugs.gnu.org Message-ID: <20200212190742.GZ1663@brightrain.aerifal.cx> References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122220515.GH30412@brightrain.aerifal.cx> <38d0e03d-4718-8085-4474-981fdef9b4b8@cs.ucla.edu> <87zhdonhxg.fsf@mid.deneb.enyo.de> <20200212130555.GX1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200212130555.GX1663@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod 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 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 to work on > > > non-symlinks, and similarly for lchmod on non-symlinks. The idea is to > > > avoid this sort of problem in the future, and to let Coreutils etc. work > > > on older platforms as if glibc 2.32 (or whatever) is already in place. > > > > The lchmod implementation based on /proc tickles an XFS bug: > > > > > > Uhg, why does Linux even let the fs driver see whether the chmod is > being performed via a filename, O_PATH fd, or magic symlink in /proc? > It should just be an operation on the inode. OK, I don't think it's actually clear from the test that the use of the magic symlink is the cause. It's plausible that XFS just always returns failure on success for this operation, and I don't have XFS to test with. 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 exists. With current kernel versions it seems that does not happen; is it safe to assume it doesn't? Further, I've found some inconsistent behavior with ext4: chmod on the magic symlink fails with EOPNOTSUPP as in Florian's test, but fchmod on the O_PATH fd succeeds and changes the symlink mode. This is with 5.4. Cany anyone else confirm this? Is it a problem? Rich