On Tue, Jul 25, 2006, EV wrote: > > That just leaves "Implement hangup(), authenticate(), request/ > > release_io_lock()". > > These calls have sense only (or mainly) for symetry with > the Ethernet interface.
So should the USB versions be implemented as no-ops or left unimplemented? > > authenticate() is just not applicable to the USB stuff. > > Don't fully agree. It could make sense to implement a (simple) > authentication mechanisme, mimicking the Ethernet behaviour.the > password could be stored, for example, along with the > device-settings file. The password is already stored by the karma in var/config.ini > If I had to vote, however, I'd say NO -- but I'd also remove (or > hide) the need for password with the Ethernet interface. I think that USB is fundamentally different. If you have the device plugged in via USB then you probably have physical access which makes any authentication mechanism somewhat pointless. In any case, the only access restrictions which count are the ones enforced by the operating system. If you put access control in libkarma then there's nothing to stop someone from just removing it. Ethernet is a different matter entirely, since it makes the device accessible to any machine on the local network. However, it is still pointless having access control in libkarma if it is not enforced by hardware. I presume that this must be the case. If so then you can't remove or hide the authentication mechanism. It is required in order to access the device. Keith. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-karma-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-karma-devel
