Skip site navigation (1)Skip section navigation (2)
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>