--jKBxcB1XkHIR0Eqt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 20, 2004 at 10:52:53AM +1100, Daniel Carosone wrote:
>=20
> The chroot case is a clear and obvious one: you want only very
> particular devices to exist, or not, and perhaps also with different
> permissions that their equivalents in the "real" /dev.  Adding a bunch
> of smart "filtering" to duplicated devfs submounts is possible, but
> seems excessive, complex and error-prone.  However, as a separate
> discussion, stronger virtualisation and isolation tools than chroot
> would also be good (systrace gets us quite a way further, but there's
> still plenty more could be done), and their benefits may more than
> compensate.

I would suggest an alternate for "duplicate" devfs mounts - new hardware=20
doesn't automatically appear in them. They only list whatever nodes the=20
admin has included in them.

> Another concern is how a dynamic devfs might interact with
> integrity-checking tools (tripwire, et al.)  If device numbers,
> permissions, ownerships, times, or indeed any stat members are
> changing, these tools will rightly get upset, and it becomes hard or
> impossible to distinguish harmless from harmful changes.  Some of
> these machines I'd presently build on physically read-only media,
> which an in-memory devfs isn't. I haven't seen a proposal to make
> devfs the mandatory and only way to do device access, at least not
> unless it can be shown to be a strict improvement for all cases (and
> not just the common default). These systems are in any case already
> heavily customised and also unlikely to have the "plug and play"
> requirements that motivate a devfs for user-friendly workstations.

I expect devfs will infact eventually become mandatory. Or at least the
common default. However I think there are ways, regardless of specific
devfs implementation option, that will address integrity-checking tools'
needs.

Note: while I've mentioned some aspects of a devfs that help
"user-friendly workstations," I also am thinking of server-class machines=
=20
too. These changes will really help with disks on SANs.

Part of why I expect (and am perhaps a bit glib) about tripwire & friends=
=20
getting fixed (even if that means NetBSD-specific or devfs-specific=20
extensions) is that we'll need these tools to work on machines not as=20
wired down as the ones you make. So once that happens, you'll have the=20
tools you need to be able to watch a devfs-based system just as you do=20
now. I expect we'll come up with something like "dstat"(2). This idea is=20
quite rough, and certainly open to comment. The idea is to permit userland=
=20
to querry the bindings (locators) for a device. Thus tripwire will be able=
=20
to make sure the locators for a node won't move around.

> Please add to this list, it's a good set of requirements to guide
> potential design.

Yes, please do. The more concerns we can think about now, the better!

Take care,

Bill

--jKBxcB1XkHIR0Eqt
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBnq7JWz+3JHUci9cRAqYwAJ0dDuiZhYD2iuAI6l4nbIEGdofVrgCdGgx8
z1AizrFf/VAZ4FujiLqUnd4=
=eXcf
-----END PGP SIGNATURE-----

--jKBxcB1XkHIR0Eqt--