From owner-svn-ports-all@freebsd.org Sat Jul 8 10:45:58 2017 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F6EDD96EBE; Sat, 8 Jul 2017 10:45:58 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50AA97C696; Sat, 8 Jul 2017 10:45:58 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1406) id 974011725; Sat, 8 Jul 2017 10:45:57 +0000 (UTC) From: Matthew Rezny To: Jan Beich Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r445016 - in head/x11/libxshmfence: . files Date: Sat, 08 Jul 2017 12:45:57 +0200 Message-ID: <2370475.W49dQvnFxO@workstation.reztek> Organization: FreeBSD User-Agent: KMail/4.14.10 (FreeBSD/11.1-BETA2; KDE/4.14.30; amd64; ; ) In-Reply-To: <201707041347.v64Dlkx7028953@repo.freebsd.org> References: <201707041347.v64Dlkx7028953@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 10:45:58 -0000 On Tuesday 04 July 2017 13:47:46 Jan Beich wrote: > Author: jbeich > Date: Tue Jul 4 13:47:46 2017 > New Revision: 445016 > URL: https://svnweb.freebsd.org/changeset/ports/445016 > > Log: > x11/libxshmfence: don't leak /tmp/shmfd* files with O_CLOEXEC > > - Both mkostemp() and mkstemp() need explicit call to unlink() > - Unobfuscate fallback if both O_TMPFILE and mksotemp() are N/A > - O_TMPFILE (Linux-only) appeared after O_CLOEXEC, no need to check > > PR: 217676 (for tracking) > MFH: 2017Q3 2017Q2 > > Modified: > head/x11/libxshmfence/Makefile (contents, props changed) > head/x11/libxshmfence/files/patch-src__xshmfence_alloc.c (contents, > props changed) > > Modified: head/x11/libxshmfence/Makefile > ============================================================================ > == --- head/x11/libxshmfence/Makefile Tue Jul 4 12:04:07 2017 (r445015) +++ > head/x11/libxshmfence/Makefile Tue Jul 4 13:47:46 2017 (r445016) @@ -2,7 > +2,7 @@ > > PORTNAME= libxshmfence > PORTVERSION= 1.2 > -PORTREVISION= 1 > +PORTREVISION= 2 > CATEGORIES= x11 > > MAINTAINER= x11@FreeBSD.org > > Modified: head/x11/libxshmfence/files/patch-src__xshmfence_alloc.c > ============================================================================ > == --- head/x11/libxshmfence/files/patch-src__xshmfence_alloc.c Tue Jul 4 > 12:04:07 2017 (r445015) +++ > head/x11/libxshmfence/files/patch-src__xshmfence_alloc.c Tue Jul 4 > 13:47:46 2017 (r445016) @@ -1,24 +1,14 @@ > --- src/xshmfence_alloc.c.orig 2015-03-04 15:28:23 UTC > +++ src/xshmfence_alloc.c > -@@ -67,15 +67,19 @@ int > - xshmfence_alloc_shm(void) > - { > - char template[] = SHMDIR "/shmfd-XXXXXX"; > -- int fd; > -+ int fd = -1; > - > - #if HAVE_MEMFD_CREATE > - fd = memfd_create("xshmfence", MFD_CLOEXEC|MFD_ALLOW_SEALING); > - if (fd < 0) > - #endif > - { > --#ifdef O_TMPFILE > -+#if defined(O_CLOEXEC) > -+#if defined(HAVE_MKOSTEMP) > -+ fd = mkostemp(template, O_CLOEXEC); > -+#elif defined(O_TMPFILE) > - fd = open(SHMDIR, O_TMPFILE|O_RDWR|O_CLOEXEC|O_EXCL, 0666); > -+#endif > +@@ -79,7 +79,11 @@ xshmfence_alloc_shm(void) > if (fd < 0) > #endif > { > ++#ifdef HAVE_MKOSTEMP > ++ fd = mkostemp(template, O_CLOEXEC); > ++#else > + fd = mkstemp(template); > ++#endif > + if (fd < 0) > + return fd; > + unlink(template); Please explain this unauthorized non-maintainer commit that lacks any PR or review. Mentioning a closed PR does notyt count. This sort of change really needs to be reviewed by the maintainer(s) before it is committed. Againb, I must assume this is wholly untested because there has been no mention of QA.