Like I said before, gphoto, sane, etc, don't have security policies.
That's the systems job, not the applications.
/sbin/hotplug, being part of the system, should solve this.
And like I said, being part of the system, its job is to
*FOLLOW* policies. The _only_ policy it has any business
defining is "default-secure". Just look at all the trouble
MSFT causes by choosing "default-unprotected"!!
Perhaps one missing piece here is the observation that security
policies should be controlled by a person, likely by whoever owns
the hardware. They're not part of the OS or the application.
Though it's worth pointing out that bundling a scanner app with
an OS makes a lot of those distinctions moot. The whole bundle
needs to be default-secure. Installing an app component into a
place like /usr/bin is effectively making it part of the OS, just
like installing a different component into /etc/hotplug/usb does.
gphoto and sane have no business telling everyone how to manage
privileges.
Actually they have every business documenting requirements and
providing tools that make it easy to satisfy those on stock
(default-secure!) systems. That's exactly what they did, last
time I checked.
One end-user front end to the security policy is always the
application anyway ... that's where a "no, you can't use the
bedroom-cam just now" policy eventually materializes in a way
that some user (FBI etc) will see.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
