From owner-svn-src-head@freebsd.org Wed Jan 6 04:09:13 2016 Return-Path: Delivered-To: svn-src-head@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 6632FA6497B for ; Wed, 6 Jan 2016 04:09:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 01BFA1860 for ; Wed, 6 Jan 2016 04:09:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qg0-x236.google.com with SMTP id b35so164931109qge.0 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=D9IWfhvqIP8/a3Ztm5kFnw8GgeF6LfNsBziOLexgDv0F6iRph5FR4bTrcZDMLWMZ2L vBOU5YbVli2VrWSUUonUzmxoS/ur08Rzh7AGvlgVTKGJnYwSdJl0xUMolECDXbI40uag +heq8MTQvV/kWZBP7R9QzU+5gU+VvX2clOISRmTnaHtEr+ckzWszZtVMiedGE8NZOK0s ZbTKGYVFNap0O/ay1PDrCETep+NuWgewl45CDRNhsUOwyuPZW1Mo8mvrpNnTYs9BIp0Q aVp7n63CeevwOCM4tOLKUVk0GkRYhnvSY9sfxFN2ldONxBQPiIHKzbOfn1qwVeST9TBy 8QLg== X-Gm-Message-State: ALoCoQkn3+JLXap6BQ5znfNvn/vKDNTR8Zwf6cFNDej17Lv8+klU6cY5RRGvMVUyXBKLmNwyAeaghoEiQh1SMzCCiMIHiwRXvA== 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-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current 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 > > >