From owner-freebsd-current@freebsd.org Mon Jun 29 19:26:35 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E3D9B353734 for ; Mon, 29 Jun 2020 19:26:35 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wctM5kmGz4Hjy; Mon, 29 Jun 2020 19:26:35 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from localhost (p548612f6.dip0.t-ipconnect.de [84.134.18.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 4E28E19257; Mon, 29 Jun 2020 19:26:35 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Mon, 29 Jun 2020 21:26:34 +0200 From: Gordon Bergling To: Ian Lepore Cc: Gordon Bergling , "Rodney W. Grimes" , Kevin Oberman , FreeBSD Current , david@catwhisker.org Subject: Re: Undeletable files after kyua test runs Message-ID: <20200629192634.GA58164@lion.0xfce3.net> References: <20200629174212.GA80071@lion.0xfce3.net> <202006291858.05TIwlGL048486@gndrsh.dnsmgr.net> <20200629190856.GA44618@lion.0xfce3.net> <934817c6a90cecc186bf06d3eec1ccba50dd834a.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <934817c6a90cecc186bf06d3eec1ccba50dd834a.camel@freebsd.org> X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 9:21PM up 2 days, 8:05, 5 users, load averages: 1.19, 1.14, 1.11 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 19:26:35 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2020 at 01:18:12PM -0600, Ian Lepore wrote: > On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote: > > On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote: > > > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > > > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling < > > > > > gbe@freebsd.org> wrote: > > > > > > I recently stumbled across undeletable files that are > > > > > > generated by kyua > > > > > > test runs, > > > > > > for example > > > > > >=20 > > > > > > -rwxr-xr-x 1 root wheel 0 May 9 13:10 > > > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit > > > > > >=20 > > > > > > I haven't yet identified the test that generate those files, > > > > > > but it is > > > > > > impossible > > > > > > to delete them. I have clear_tmp_enable=3D"YES" set in the > > > > > > /etc/rc.conf, but > > > > > > on every boot the system argues that these file aren't > > > > > > deletable. > > > > > > I tried to 'rm -rf' them by hand but, even this wasn't > > > > > > possible. I have > > > > > > looked for > > > > > > any extend attributes, but I didn't find any. > > > > > >=20 > > > > > > Has anyone an idea how this is possible and may how these > > > > > > files can be > > > > > > deleted? > > > > >=20 > > > > > Have you done 'ls -o' to check for flags like schg? > > > > > -- > > > > > Kevin Oberman, Part time kid herder and retired Network > > > > > Engineer > > > > > E-mail: rkoberman@gmail.com > > > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > >=20 > > > > Argh, I haven't thought about chflags for quite some time. The > > > > chflags > > > > bit was set and after an > > > >=20 > > > > # find /tmp/ -type f -exec chflags -R 0 {} \; > > >=20 > > > ^^Only files ^^ meaningless when chflags is > > > given ONLY files > > >=20 > > > You probably could of done: > > > chflags -R 0 /tmp/ > >=20 > > Okay, I am currently working on an update for clear_tmp_enable=3D"YES" > > to include > > a check like this. I would think that an rc option like this should > > delete=20 > > everything in /tmp. > >=20 >=20 > I disagree. One of the few things those immutable flags are good for > is protecting files from things like an rc script or other automation > that deletes files. Those flags are typically set and maintained by > users and admins, and automation should not change them in order to > delete files. >=20 > The real fix we need is for the kyua tests to properly clean up after > themselves, including fixing the flags on temporary files created or > used by the tests, and then deleting them. >=20 > -- Ian A fix for the causing RC script was my first idea, but I had of course the same idea that a kyua test could be fixed to not end in a state that leads to file that has chflags set to a value that couldn't be deleted by a job that is proposed to so. I take this as a homework and look at the kyua scripts that created those files. --Gordon --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAl76QGlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP 09yckAf/ShcqQRmAVH/F28e/syV5fm8GQbLEJVdDXPwZXyjp5BQ1jSWxQDQP73QR Fde0oReiF5v3zjkiYC01yZvcsFLq3+3s5Rm9DAZ7SmdHYPkSkNn9XWOiau+2QjSv MqlKSDYJ+JGR4Ok7rXy2akejvUmJEAbWJRMx9ZDrqxLtLpWLHu7pafv2UIXyE939 618gyyf7+O6CHFo7otwmTwahUQEafgPbbXdRVAkdFeHp5rGCOPVYSlsKkxy+Xcx0 zG7ohEX+HiXy8BduWOnOhA4wp94rxDo8Mv6IOUtAr6T9Zc1+ximXv77DqhBspAyM p6zOMxZj8M9xz+wveaqdhmRsMJn+GQ== =U1Va -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd--