Date: Wed, 6 Jan 2016 17:40:16 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Allan Jude <allanjude@freebsd.org> Cc: Devin Teske <devin@shxd.cx>, Bruce Evans <brde@optusnet.com.au>, Ian Lepore <ian@freebsd.org>, Warner Losh <imp@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Devin Teske <dteske@freebsd.org> Subject: Re: svn commit: r293227 - head/etc Message-ID: <20160106163237.L1563@besplex.bde.org> In-Reply-To: <568C883C.5050006@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160106163237.L1563>