From owner-svn-src-all@freebsd.org Wed Jan 6 04:09:13 2016 Return-Path: Delivered-To: svn-src-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 3F5FDA6497A for ; Wed, 6 Jan 2016 04:09:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1CCE185B for ; Wed, 6 Jan 2016 04:09:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qg0-x22c.google.com with SMTP id 6so216546873qgy.1 for ; Tue, 05 Jan 2016 20:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=n/rDpO9XPbLTcNBXluthFTzsTTCCquKp1WjQgDl6hWM=; b=glOhL0uMtamtW3aTwSh3E20z/mFf/XXZM3nD8HRub76G/IkjfGTEu9I9FgK90MHb8P ZN5nrVbbJ8Q005O4L2rv0PSGnR4NlHT2V295MCi8IVWrb+ER4hL6LvTjZkYDIY3uI9zf GASJPzFHzKxZeZUnEZbY3Gu3AMnyNaekaPGnEip8FiFt8OzvKQkHutsYM+dNuSoSYf06 mvfcHXcS6Ex7pBVKZWAo39EyZnOLYBvueM3KMWAtthd6zq3Rk7jFywmV81cXpz/iwwtB /7Hu9B7dhCkMTnTwfNb5dpeTyq6WI+zRKVETId0TapMDjIOU7Pr9WSm4erznXMZ2ek3K An3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n/rDpO9XPbLTcNBXluthFTzsTTCCquKp1WjQgDl6hWM=; b=LqpWN62b1GqY2D1yz0XX944/nkXbKpsrT92xBPeHTFt3y1BBivUWK6OJ6AVYsWflop AwYbyTOjtyK6ZPh0qaATbX6Ru9u+IWJCKQBn2PVRLMupPVDvMJH+U/C4mQlyOjYg7FTc Od1V2mu4GD9njccXZImEED6ap2QFlH2gfkB/PEaYaUCdoU8dxcpR4NxvzAnufizgC80L 7FVlrQNkW6dj6Zw+5ZeyjXaxvu55jP+OyvocFUnaMFTHI9jG5WcwqdE16flaWCN8ReLJ Y7qp1gGJ9zbei2L1BsqEtMNgwH7dagTZrExr2NIJYEVwzwXKJDRsAT2yzrDwdFTAi/RD ySyw== X-Gm-Message-State: ALoCoQmjK3izoKQEudwJSkNonScywEYA2bwf7WEIk7IHcqynrgw4pcnKeMFgoMjcqeKXjzdsVAbymjEOvccoZe1PQKR+UueOSg== MIME-Version: 1.0 X-Received: by 10.140.109.247 with SMTP id l110mr70660799qgf.52.1452053351666; Tue, 05 Jan 2016 20:09:11 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Tue, 5 Jan 2016 20:09:11 -0800 (PST) X-Originating-IP: [2601:280:4900:3700:e564:ecab:50db:6e5f] In-Reply-To: <5360EA7A-399F-4679-B58F-62D0112EA481@shxd.cx> References: <201601052120.u05LKlQw074919@repo.freebsd.org> <1452038404.1320.46.camel@freebsd.org> <20160106125617.E968@besplex.bde.org> <5360EA7A-399F-4679-B58F-62D0112EA481@shxd.cx> Date: Tue, 5 Jan 2016 21:09:11 -0700 X-Google-Sender-Auth: OHf0O02Uwt76UJBZzBKHXa5DDVY Message-ID: Subject: Re: svn commit: r293227 - head/etc From: Warner Losh To: Devin Teske Cc: Bruce Evans , Ian Lepore , Warner Losh , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , Devin Teske Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 04:09:13 -0000 The correct fix is chflags -R 0 firstboot rm -rf firstboot If you still can't remove it, too bad. Checking to make sure it worked really isn't the unix way. Sometimes when you do stupid things, stupid results happen. Warner On Tue, Jan 5, 2016 at 8:16 PM, Devin Teske wrote: > This e-mail is extremely hard to parse and I think you are mistaken. > > The -f flag is more than just a counter to a possible -i > > Try to rm a file that has schg > You will get a prompt without -i > Adding -f will abate the prompt to attempt override of schg flag. > > There are more conditions in rm that lead to a prompt than simply those > conditions involving -i and adding -f abates them all. > > -- > Devin > > > On Jan 5, 2016, at 6:48 PM, Bruce Evans wrote: > > > > On Tue, 5 Jan 2016, Ian Lepore wrote: > > > >>> Log: > >>> Use the more proper -f. Leave /bin/rm in place since that's what > >>> other rc scripts have, though it isn't strictly necessary. > > > > "proper -f" is hard to parse. I think you mean: > > > > Use 'rm -f' to turn off -i in case rm is broken and is an alias which > > has -i (and perhaps actually even something resembling rm) in it. More > > precisely, use 'rm -f /usr/bin' to partly defend against the same bug > > in /bin/rm (where it would be larger). Keep using /usr/rm instead of > > restoring the use of plain rm since that is what other rc scripts have. > > The previous change to use /bin/rm instead of plain rm was neither > > necessary nor sufficient for fixing the bug. Neither is this one, but > > it gets closer. It is a little-known bug in aliases that even absolute > > pathnames can be aliased. So /bin/rm might be aliased to 'rm -ri /'. > > Appending -f would accidentally help for that too, by turning it into > > a syntax error, instead of accidentally making it more forceful by > > turning -ri into -rf. > > > > Hopefully this is all FUD. Non-interactive scripts shouldn't source any > > files that are not mentioned in the script. /etc/rc depends on a secure > > environment being set up by init and probably gets it since init doesn't > > set up much. sh(1) documents closing the security hole of sourcing the > > script in $ENV for non-interactive shells, but was never a problem for > > /etc/rc since init must be trusted to not put security holes in $ENV. > > But users could put security holes in a sourced config file like > > /etc/rc.conf.local. > > > >>> Modified: head/etc/rc > >>> ===================================================================== > >>> ========= > >>> --- head/etc/rc Tue Jan 5 21:20:46 2016 (r293226) > >>> +++ head/etc/rc Tue Jan 5 21:20:47 2016 (r293227) > >>> @@ -132,9 +132,9 @@ done > >>> # Remove the firstboot sentinel, and reboot if it was requested. > >>> if [ -e ${firstboot_sentinel} ]; then > >>> [ ${root_rw_mount} = "yes" ] || mount -uw / > >>> - /bin/rm ${firstboot_sentinel} > >>> + /bin/rm -f ${firstboot_sentinel} > >>> if [ -e ${firstboot_sentinel}-reboot ]; then > >>> - /bin/rm ${firstboot_sentinel}-reboot > >>> + /bin/rm -f ${firstboot_sentinel}-reboot > >>> [ ${root_rw_mount} = "yes" ] || mount -ur / > >>> kill -INT 1 > >>> fi > >> > >> Using rm -f to suppress an error message seems like a bad idea here -- > >> if the sentinel file can't be removed that implies it's going to do > >> firstboot behavior every time it boots, and that's the sort of error > >> that should be in-your-face. Especially on the reboot one because > >> you're going to be stuck in a reboot loop with no error message. > > > > Er, -f on rm only turns off -i and supresses the warning message for > > failing to remove nonexistent files. But we just tested that the file > > exists, and in the impossible even of a race making it not exist by > > the time that it runs, we have more problems than the failure of rm > > since we use the file's existence as a control for other things. > > > > So the only effect of this -f is to turn off -i, which can only be set > > if the FUD was justified. > > > > The correct fix seems to be 'unalias -a'. > > > > Bruce > > >