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.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|