Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Nov 2002 00:33:59 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        kip@eventdriven.org
Cc:        Bruce Evans <bde@zeta.org.au>, Kris Kennaway <kris@obsecurity.org>, current@FreeBSD.ORG
Subject:   Re: Device permissions with DEVFS
Message-ID:  <3DD9F777.2502F3F0@mindspring.com>
References:  <20021119081649.13088.qmail@web14008.mail.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Kip Macy wrote:
> Sorry, if I'm repeating something already said, but
> the tone of your mail would indicate that I'm not.
> 
> This doesn't sound like an intrinsic limitation of
> devfs, just an issue with how it is structured now.
> There should just be a central file for all the
> devices which devfs sucks in at build (or maybe boot)
> time specifying the appropriate permissions and any
> other configuration information.

A separate ELF data section for this information would allow
kernel modules to have this information edited with a tool,
as well permitting the kernel itself to be edited with the
same tool, so that site defaults could be persistantly changed
from the source tree defaults.

Indeed, this would allow the permissions to be listed in the
case that Bruce was complaining about, which is the inability
to see what will happen when the hardware is present, if it's
not available to the tester.

An extension of this would permit chmod's against the devfs
to be "written back" to the kernel or driver module affected,
assuming your secure level is low enough and your flags are
set to permit it, which also gets rid of the common complaint
about persistance (which is really just a handy thing to use
to bitch about devfs when you can't come up with any legitimate
complaints, IMO).

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DD9F777.2502F3F0>