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

On Wed, Dec 01, 2004 at 03:11:38AM -0500, Matthew Orgass wrote:
> On 2004-11-30 wrstuden@NetBSD.org wrote:
> > On Tue, Nov 30, 2004 at 03:54:33AM -0500, Matthew Orgass wrote:
>=20
> > Uhm, I don't think we need the "blessing" step as userland will be the
> > agent creating the device node, in this scheme. Removing the node on
> > deletion sounds good too.
>=20
>   Something is needed to avoid a race condition with a new device taking
> the name before the permissions are reverted, although the reference I
> suggested for locators might be a better way to do this.  While any
> references are held the device name will never be reused, so the userland
> program holds a reference from attach until the node is deleted after
> detach.

Huh?

The device management system (whatever controls node names and=20
permissions; either the in-kernel devfs or the userland daemon) controls=20
both the appearance of a device node and its permissions. So I don't=20
understand why we need special steps for it to prevent race conditions. It=
=20
certainly should be able to operate without races..

> > As to issues involving errors on write, I think a rather simple solution
> > is to have two copies of the file and ping-pong between them.
>=20
>   If they are separate you can use a text file for the permissions map and
> a binary file for the atime preservation.  IIRC you were advocating a
> single permissions system with automatic tracking of the in use
> permissions.  In that system, what you describe might make sense.  What I
> was suggesting is that there is a file in /etc that contains the default
> permissions based on cannonical device name (i.e.  device name + minor
> number; major numbers would be directly replaced by symbolic names; I do
> now see the problem with this, more below).  It also contains further
> modifications to the permissions based on locator, but the altered
> permissions will be applied to the cannonical device name.  Further
> changes made to a running devfs by the admin would be applied only to that
> instance and will go away forever when the device detaches.  This both

Uhm, one point of all of this is that the permissions DON'T just go away=20
forever when the device detatches.

> preserves cannonical reference and makes it possible to modify permissions
> based on locator.  Use based on locator would need to be handled
> separately.
>=20
>   The main problem I see with automatic permission tracking is that with
> permissions based on locators a simple chmod will not be an unambiguous
> permissions change unless you also require the admin to know all possible
> locators in order to difinitively change permissions on a physical device.
> With a separate permissions file you get a more descriptive language and
> potentially the ability to check for some conflicts before making changes.

I do not see the ambiguity, as my expectation is that if you chmod a node,=
=20
you are chmod'ing the entity with the name and locators that vnode is=20
using.

> > Why? Note that there is a difference between the device having default
> > permissions and the node showing up. In all the devfs proposals I've se=
en,
> > there either has been an explicit hook for policy upload to the kernel
> > (the binary file idea I've suggested) or userland daemons (what you're
> > proposing), or there could be one (devfs on other nodes, say symlinks).=
 So
> > there is a space to say, "don't just add nodes." Thus the act of the
> > device showing up (with the despised, uncontrolled default permissions)
> > can be easily stopped.
>=20
>   I think that devices should never appear with permissions unknown to the
> administrator.  If default permissions are stored in the driver, a kernel
> update can change your device permissions.  You should not need to set an

You're assuming that userland has never noted the previous permissions.

My take on default permissions is that they are a guide to what the node=20
should show up the very first time. Once a node's shown up (and certainly=
=20
after it'd been used), I'd expect its permissions to not move, even if the=
=20
"default" permissions change.

> option for that to not happen.  Furthermore, the kernel does not manage
> users and other than root has no business assuming that a particular
> number corresponds to a particular user.  There seem to currently be
> default entries owned by uucp as well as root.  Updating the devfs should
> not be needed frequently nor should it be particularly difficult.  I think
> a single global default for unmatched devices (specified in the devfs
> config file) that would be very restrictive (no access) would be a good
> thing, possibly even a good default.  With that in place if you update
> your kerenel and get new devices but forgot to import permissions for
> them, you would still see them in /dev and be reminded to set them.
>=20
> > The only locator namespace I've had in mind, and the only one I've
> > understood other folks have had in mind, is that of kernel devices. i.e.
> > config locators, the things you can put in kernel config files.
>=20
>   I was a little confused about locators, but not too much (read the first
> sentance as WRT devfs).  Devices can have more than one locator, so what I
> am most concerned about here is that no part of the kernel refer to a
> device without also referring to the cannonical name.  From your message:
> http://mail-index.NetBSD.org/tech-kern/2004/11/20/0018.html
> I can't tell how you intend to treat device names elsewhere in the kernel.

Why do we need cannonical name?

I think you're on a different page than the rest of us. That's not to say=
=20
we can't learn from each other, just that I think you're raising issues=20
the rest of us had assumed were solved differently.

Take care,

Bill

--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBrh3wWz+3JHUci9cRAg8lAKCD0FYHbJOcV0Ds3rf4bBAmkJlCiwCfRndQ
XN/8Zq5GWZoc2M+knY8tD/g=
=PEwA
-----END PGP SIGNATURE-----

--VS++wcV0S1rZb1Fb--