Date: Fri, 15 May 2020 07:51:42 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Kyle Evans <kevans@freebsd.org> Cc: Alan Somers <asomers@freebsd.org>, "Julian H. Stacey" <jhs@berklix.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, "freebsd-hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <35501.1589529102@critter.freebsd.dk> In-Reply-To: <CACNAnaFDHMkConkBLY-2BMAudueDA8-HTJ5_FNpt4WrB=gg_HA@mail.gmail.com> References: <CACNAnaFszg%2BQWPRS0kghsnQMxXc%2B5niPTTNiUPSmK60YyBGCzA@mail.gmail.com> <202005142017.04EKH0aA093503@fire.js.berklix.net> <CAOtMX2i2Z-KX=3rYR2nZ1g1Lb_tF==H3xPKcQMBxJs1Kqr-meQ@mail.gmail.com> <33549.1589488226@critter.freebsd.dk> <CACNAnaFDHMkConkBLY-2BMAudueDA8-HTJ5_FNpt4WrB=gg_HA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- In message <CACNAnaFDHMkConkBLY-2BMAudueDA8-HTJ5_FNpt4WrB=3Dgg_HA@mail.gma= il.com> , Kyle Evans writes: >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp <phk@phk.freebsd.dk> 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= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35501.1589529102>