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 0c86762e for ; Wed, 22 Jan 2020 17:15:26 +0000 (UTC) Received: (qmail 9527 invoked by uid 550); 22 Jan 2020 17:15:25 -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 9509 invoked from network); 22 Jan 2020 17:15:24 -0000 Date: Wed, 22 Jan 2020 12:15:08 -0500 From: Rich Felker To: Florian Weimer Cc: 39236@debbugs.gnu.org, musl@lists.openwall.com Message-ID: <20200122171508.GD30412@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> <20200122151507.GB30412@brightrain.aerifal.cx> <87zhefik0y.fsf@oldenburg2.str.redhat.com> <20200122160743.GC30412@brightrain.aerifal.cx> <87v9p3ihvq.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v9p3ihvq.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] coreutils cp mishandles error return from lchmod 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, 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 lchmod always returns ENOSYS (except on Hurd). I don't know how > >> >> >> lchmod is used in coreutils, but I suspect it is not particularly > >> >> >> useful. > >> >> > > >> >> > When preserving permissions (cp -p, archive extraction, etc.), you > >> >> > want lchmod to work correctly just for the purpose of *not* following > >> >> > the link and thereby unwantedly changing the permissions of the link > >> >> > target. But, fchmodat with AT_SYMLINK_NOFOLLOW works just as well and > >> >> > is standard, and that's really what coreutils should be using. > >> >> > >> >> 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. > >> > > >> > Yes, I understood that. I was going into why there should be a real > >> > implementation, but didn't make it clear that that was what I was > >> > doing. > >> > >> Ah, yes, there should be a real implementation if we can get full > >> lchmod/AT_SYMLINK_NOFOLLOW behavior on file systems that support it. If > >> we can't, I'm not sure if there is a point to it. > > > > The point is to fail when the target is a symlink, rather than > > (erroneously and possibly dangerously) applying the chmod to the link > > target. Actually supporting link modes is useless. It's the "not > > modifying the target" that's important. > > The kernel supports it on some file systems, though: > > $ ls -l /tmp/x > l---------. 1 fweimer fweimer 6 Jan 22 15:27 /tmp/x -> /tmp/x > > Although mode 0 curiously does not prevent readlink calls. > > > It's explained in the bz you just replied on, > > https://sourceware.org/bugzilla/show_bug.cgi?id=14578 > > > > The point of the S_ISLNK check is to fail out early with the ENOTSUPP, > > which the caller should treat as "success-like", in the non-racing > > condition, without the need to open a fd (which may fail with > > ENFILE/EMFILE) and without the need for /proc to be mounted. > > Otherwise, a different error will be produced when one of those cases > > is hit, and the caller will treat it as a real error. > > 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? Maybe that's ok. I was concerned it might follow the link and chmod the target at that point. I thought you were asking about the ealier check before the O_PATH open. Rich