On Wed, Apr 19, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> Johannes Erdfelt writes:
> > I noticed that COPY was a new feature in devfsd.
> >
> > I'd like to implement something similar for USB, but which tracks the
> > device.
> >
> > Or, if the device is new (not previously known to be plugged into
> > this system), could be given a default set of permissions based on
> > configuration options.
>
> You should already be able to do that with the PERMISSIONS action.
> With the regex engine, you should have a lot of flexibilty in managing
> permissions. I basically see PERMISSIONS as the preferred way of
> managing permissions for hot-plug devices.
>
> > COPY unfortunately will make it difficult to track USB devices since
> > the information tracked is the filename and it is store as a file.
>
> I didn't really see COPY as being all that useful for USB.
>
> I should point out that I see two distinct families of devices in
> devfs. The "classic" devices, which are pretty much static, and
> "dynamic" devices such as USB.
>
> For classic devices, most people want the old permissions
> semantics. Hence COPY.
>
> For dynamic devices, we really need a different mechanism, hence
> PERMISSIONS.
>
> > I'd like to use a database (berkeley, gdbm, text, etc) to store the
> > information necessary. Perhaps in addition to the current scheme of
> > storing the information in the filesystem via a different tree.
>
> How is PERMISSIONS insufficient for your needs?
>
> > In most cases, we would use the serial number to track the device.
> >
> > I'd like to make it flexible enough to track based on vendor/product
> > and possibly bus topology for those people who wish to use it.
>
> Is this perhaps USB-specific? If so, we could leave this to the USB
> extension for devfsd. This level of flexibility sounds quite complex,
> and I don't know if there is a generic scheme that could be applied.
>
> Also, I don't see the advantage of using a database, rather than just
> a directory tree. It seems to me that the hard part is in deciding
> what to store and "where", and in deciding what to extract. That's all
> policy, and is probably USB specific.
>
> The actual mechanisms for storing and extracting permissions would
> seem to be trivial.
It's all dynamic. I'd rather not rewrite the config file with dynamically
generated information.
It could be specific to the module, but I suppose other systems will have
similar issues. Firewire, hot plug PCI, etc.
How do we want to handle USB specific options?
For instance, the driver database (this is relatively static). The location
of the device permissions tracking database.
JE
|