Date: Fri, 15 May 2020 14:22:46 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: Kyle Evans <kevans@freebsd.org>, 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: <202005152122.04FLMkd8007214@slippy.cwsent.com> In-Reply-To: <35501.1589529102@critter.freebsd.dk> 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> <35501.1589529102@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <35501.1589529102@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > -------- > In message <CACNAnaFDHMkConkBLY-2BMAudueDA8-HTJ5_FNpt4WrB=gg_HA@mail.gmail.co > m> > , Kyle Evans writes: > >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote > : > > >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=999` 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. A kern.geom.debugflags-like thing might help but the complexity the code remains. Kyle's patch reduces complexity to a degree. A debugflags sysctl won't, it will add a little complexity. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202005152122.04FLMkd8007214>