Re: [ANNOUNCE] udev 0.1 release

[David Lang]

you can only do this if you use a virtual directory for dev, otherwise you
have to do something like scanning /dev at shutdown and storing the
result (this was the famous devfs tar archive of permission issue)

you really ahve two situations.

1. a virtual filesystem for /dev.

  this lets you notice all changes to anything in /dev and store it
apropriatly

2. a real filesystem for /dev with a userspace daemon to update it.

  this involves the kernel less, but unless you can convince people to
stop managing their devices the old way you have the problem of missing
changes

David Lang

 On Fri, 11 Apr 2003, Steven Dake wrote:

> Date: Fri, 11 Apr 2003 15:32:57 -0700
> From: Steven Dake <[e-mail]>
> To: Greg KH <[e-mail]>
> Cc: David Lang <[e-mail]>,
>      "Perez-Gonzalez, Inaky" <[e-mail]>,
>      'Jeremy Jackson' <[e-mail]>,
>      "'[e-mail]'" <[e-mail]>,
>      "'[e-mail]'"
>     <[e-mail]>
> Subject: Re: [ANNOUNCE] udev 0.1 release
>
>
>
> Greg KH wrote:
>
> >On Fri, Apr 11, 2003 at 01:48:17PM -0700, David Lang wrote:
> >
> >
> >>ant then you also have all the same problems as devfs about default
> >>permissions, making permissions persistant across reboots, etc.
> >>
> >>
> >
> >You can store the default permissions in the database you use to store
> >the naming data.  This solves the reboot problem, as long as you can
> >convince people to not modify the permissions on their own (well even if
> >they do, at shutdown, you can always validate that they are the same
> >before you clean up the node.)
> >
> >And provide an easy way for users to change the permissions so they show
> >up in the database.
> >
> >devchmod and devchown anyone?  :)
> >
> >
> Greg,
>
> I've been thinking of how to solve this particular problem, and believe
> you could use dnotify in a daemon to track permission and ownership
> changes and store them in a backing database.  In fact, we do something
> similiar to this today.  This allows the user to use any type of
> application for changing permissions/owners, even syscalls directly
> without having to go "through" any sort of tracking database.
>
> >thanks,
> >
> >greg k-h
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to [e-mail]
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at  http://www.tux.org/lkml/
> >
> >
> >
> >
> >
>