From owner-freebsd-arch@freebsd.org Fri May 15 07:51:47 2020 Return-Path: Delivered-To: freebsd-arch@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 18B3B2ED2BB; Fri, 15 May 2020 07:51:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NgbP30b7z4VdH; Fri, 15 May 2020 07:51:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id C2E501AF18C; Fri, 15 May 2020 07:51:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id 04F7pgrH035503 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 07:51:42 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id 04F7pgXZ035502; Fri, 15 May 2020 07:51:42 GMT (envelope-from phk) To: Kyle Evans cc: Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: From: "Poul-Henning Kamp" References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35500.1589529102.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2020 07:51:42 +0000 Message-ID: <35501.1589529102@critter.freebsd.dk> X-Rspamd-Queue-Id: 49NgbP30b7z4VdH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.78 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.872,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.95)[-0.954,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.04)[ip: (0.06), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.08), country: EU(-0.01)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 07:51:47 -0000 -------- In message , Kyle Evans writes: >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wr= ote: >Can we explore the possibility of using fsdb(8) to fulfill these needs >in a way that you'd be comfortable with? First, I am perfectly comfortable with fsdb(8), but in both the two scenarios it was much less timeconsuming to do: strings < /some/directory | head Which immediately gives you the first filenames in the directory, without waiting for ls(1) to read the entire directory, which in this case was well north of 100MB. In the other case hexdump -C < /some/directory | grep part_of_suspect_filename gave me the answer faster than I could have started fsdb, it gave me the answer in convenient hexadecimal, and besides it was not = a UFS filesystem. Second, one of the major reasons, probably about 3/4 of the total reason I ended up in FreeBSD, was because of some utterly shit experiences with commercial operating systems, where I had been in a tight corner at 00-dark o'clock, and run straight into something some idiot of at the vendor thought root should not be able to do "for their own safety". This change falls right into that category: If root wants to hexdump a directory, an entire bloody disk, or even if root wants to go and do binary surgery on a mounted file system with a hex-editor, root should be able to do that. She may have to `sysctl kern.warranty_voided=3D999` first, to disable *under normal circumstances* reasonable and sensible protections. I'm perfectly fine with that: We do not want to make being root a minefield, and I myself put the ability to munge mounted filesystems under such a interlock in GEOM. But we should not make it *impossible* to do these things, and in particular, we should not make them require a reboot, because ten times out of nine, when you find yourself doing this kind of shit, it is usually because you're pretty sure everything is lost if you reboot. Summary: I'm perfectly fine with read(2) returning error on a directory *under normal circumstances*, and I think it makes good sense by protecting a lot of terminals from a lot of binary garbage. But there is absolutely no reason to make it *impossible* for a competent root to do what competent roots do. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .