From owner-svn-src-all@freebsd.org Thu Jan 7 17:02:05 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 B6F9DA66A92; Thu, 7 Jan 2016 17:02:05 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6691329; Thu, 7 Jan 2016 17:02:05 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.1] (unknown [192.168.1.1]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id B93AEDB50; Thu, 7 Jan 2016 17:02:04 +0000 (UTC) Subject: Re: svn commit: r293227 - head/etc To: Bruce Evans References: <201601052120.u05LKlQw074919@repo.freebsd.org> <1452038404.1320.46.camel@freebsd.org> <20160106125617.E968@besplex.bde.org> <5360EA7A-399F-4679-B58F-62D0112EA481@shxd.cx> <568C883C.5050006@freebsd.org> <20160106163237.L1563@besplex.bde.org> Cc: Devin Teske , Ian Lepore , Warner Losh , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Devin Teske From: Allan Jude Message-ID: <568E9A06.8090500@freebsd.org> Date: Thu, 7 Jan 2016 12:01:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160106163237.L1563@besplex.bde.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 07 Jan 2016 17:02:05 -0000 On 2016-01-06 01:40, Bruce Evans wrote: > On Tue, 5 Jan 2016, Allan Jude wrote: > >> On 2016-01-05 22:16, 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. > > I forgot about the permissions check. Normally root has permission to > write anything, but some file flags change this. The schg flag is > handled bogusly: rm prompts without -f, but schg prevents removal if > you answer 'y'. The uchg flag is handled better. rm has special > undocumented code to handle it, mainly so that rm -rf blows it away. > Without -f, rm prompts but the the special code removes uchg so that > removal is possible. > > The permissions check only applies to the file. Removal doesn't > depend on the file's permissions. It only depends on the file's flags > and the directory's permissions and flags. rm agrees with its man > page and doesn't prompt if the file is writable but the directory is > unwritable. The directory permissions don't stop root either, but > immutable directories do. Since there is no prompt, -f has no effect > on anyone in this case. > >>> There are more conditions in rm that lead to a prompt than simply >>> those conditions involving -i and adding -f abates them all. > > It isn't clear what these are. POSIX only says that there is a prompt > without -i for files which don't have write permission (to themselves). > FreeBSD's man page should say more about how this extended for file > flags, but actually says nothing for file flags and is less clear than > POSIX for ordinary permissions. > >> I think this is kind of a poor UI design of rm(1) honestly. It seems >> like what we need is a 'never be interactive' flag, that won't surpress >> the error message about the schg'd file, or read-only file system, but >> won't try to prompt for it. >> >> Although adding a new flag to rm(1) at this point probably doesn't make >> sense. > > It already has this flag, namely -f. This is what I started out to say. > -f never suppresses errors except ENOENT for a non-existent file. What it > suppresses is prompts. Since the uchg hack involves a prompt, -f also > changes the semantics for removing user-immutable files. > > The file flags hack includes uappnd together with uchg, but not the > newfangled uunlnk. That has only been available for annoying sysadmins > since 1997. Apparently its name is to confusing for it to be used. > > Bruce > In most of the cases involved in the firstboot script, the cause of the prompt is that the file system is mounted readonly. So Warner's solution of mounting the filesystem rw, doing the rm, then reverting it to readonly would seem to work, although I wonder if there is a case where the file system was NOT readonly at the start of the script, and ends up read only at the end. -- Allan Jude