From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58064 invoked by alias); 2 Jul 2018 19:46:39 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 57066 invoked by uid 89); 2 Jul 2018 19:46:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=complaints X-HELO: relay1.mentorg.com Date: Mon, 02 Jul 2018 19:46:00 -0000 From: Joseph Myers To: Paul Eggert CC: Florian Weimer , , Gnulib bugs Subject: Re: [PATCH] Add renameat2 function [BZ #17662] In-Reply-To: <4a9cb334-48f4-139f-d917-457ce8ece57a@cs.ucla.edu> Message-ID: References: <20180630121447.E4C8643994575@oldenburg.str.redhat.com> <4a9cb334-48f4-139f-d917-457ce8ece57a@cs.ucla.edu> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-07/txt/msg00039.txt.bz2 On Mon, 2 Jul 2018, Paul Eggert wrote: > The Gnulib renameat2 function > has > different semantics with non-zero flags. On GNU/Linux if > flags==RENAME_NOREPLACE and the Linux syscall fails due to > EINVAL/ENOSYS/ENOTSUP, Gnulib renameat2 falls back on fstatatting the > destination, failing if fstatat succeeds, and using ordinary renameat > otherwise. Of course this implementation has a race condition, but > Gnulib-using applications like GNU 'mv' prefer this implementation since if > the kernel doesn't support RENAME_NOREPLACE they'd just fall back on fstatat > themselves anyway, if renameat2 didn't do that for them. We've had complaints in glibc about fallbacks that introduce races (e.g. for pselect). Do you have reason to believe that this race is somehow different and introducing it will never cause problems for users? There are other possible fallbacks an application could try depending on the files it's trying to rename and what failure conditions it wants to allow for - for example, a linkat/unlinkat pair, when renaming a non-directory that's not at the maximum link count, would also guarantee not to replace an existing destination, at the risk of leaving two links if the source directory is read-only, the destination directory is writable, and the destination directory is made read-only during the renameat2 execution before it tries to remove the destination link after removing the source link failed. -- Joseph S. Myers joseph@codesourcery.com