[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-security-discuss
Subject:    Re: please help on a daemon privilege issue
From:       Colin Zou - Sun Microsystems <Colin.Zou () Sun ! COM>
Date:       2008-06-03 2:52:52
Message-ID: 4844B204.1070502 () sun ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Nathan Bush wrote:
> Colin Zou wrote:
>   
>> Let me explain this in detail. Take Cable Association as an example, the 
>> whole association process is as following:
>>
>> 1. user plug the WUSB device to a usb port on the PC box.
>> 2. the Soalris USB framework (usba(7D) and ehci(7D)) gets the device 
>> plug event and enumerates the device as a wired USB device.
>> 3. usba attach the wusb_ca driver to the device. wusb_ca driver is a 
>> newly introduced driver for Cable Association only. It is a normal wired 
>> USB driver developed on wired USB driver API, fully compliant to Solaris 
>> USB framework.
>> 4. User run wusbadm tool to specify with which WUSB host the device 
>> should be associated.
>> 5. wusbadm tool sends a request to wusbd, who will then open the device 
>> node created by wusb_ca USB driver.
>> 6. wusbd talk to the device via wusb_ca driver to create a CC. It then 
>> store the CC to CC database in file system, in the mean while, it loads 
>> the CC to the WUSB host driver.
>> 7. wusbd then complete the association request from wusbadm tool.
>> 8. Association is done. User then unplug the device. wusba_ca driver is 
>> then dettached.
>>
>> After the above is done, user can then turn on the device radio to 
>> connect the WUSB device with host over air. The subsequent wireless 
>> enumeration is the same as wired USB. A newly introduced WUSB host 
>> driver (e.g., whci) is developer on the existing Solaris USB framework 
>> (usba). whci driver gets the device radio signal and consider it as a 
>> device plug event. It passes the event to usba framework module, the 
>> latter then load an existing USB device driver (e.g. usbprn(7D) if the 
>> device is a WUSB printer) to attach to the WUSB device.
>>
>> If user reboot the system, wusbd daemon will load the CCs stored in the 
>> CC database to WUSB host driver instances. So that WUSB host can be 
>> ready to connect the associated devices.
>>
>> Please note that, it is necessary to have a daemon (wusbd) because the 
>> daemon can load CCs to WUSB host drivers automatically after system 
>> reboot. Users want the WUSB device just work after each reboot, instead 
>> of manually running a tool to load CCs.
>>     
>
> It seems that the functionality of wusbd is triggered in two cases:
>
> 1) By an explicit request from wusbadm, during the initial WUSB context
>     creation process.
> 2) Automatically at bootup, to load the CC's into host drivers.
>
> So, is a new daemon really needed?  It seems that the functions of
> wusbd used in (1) above could be implemented in the wusbadm program
> itself, and (2) above could be accomplished by a transient SMF service
> that invokes wusbadm again with correct options.  I think the coreadm
> service (svc:/system/coreadm:default) is a good example of this model.
>
>   
Sorry that I didn't mention another case that WUSB needs a daemon. The 
WUSB industry has a kind of hotpluggable WUSB host, it is a USB2.0 
dangle called HWA (Host Wire Adapter). When a HWA device is plugged, the 
hwahc driver, which is developed on usba driver API, will attach to it. 
But, before it is ready to connect WUSB devices, there must be a daemon 
to load the CCs to the hwahc driver instance after the HWA plug event. 
So, besides case (2) above, the wusbd daemon also needs to listen to the 
HWA plug event and load the corresponding CCs to the hwahc driver instance.

Another consideration about the daemon is, the action of loading CC 
should be something opaque to end users. It should just work 
automatically and should not appear in the command line interface. 
Please note that WUSB is mainly for desktop/laptop users. We have to 
have an interface design which is easy for end users.

Thanks,
Colin

[Attachment #5 (text/html)]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Nathan Bush wrote:
<blockquote cite="mid:4844996E.5030308@sun.com" type="cite">
  <pre wrap="">Colin Zou wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Let me explain this in detail. Take Cable Association as an example, the 
whole association process is as following:

1. user plug the WUSB device to a usb port on the PC box.
2. the Soalris USB framework (usba(7D) and ehci(7D)) gets the device 
plug event and enumerates the device as a wired USB device.
3. usba attach the wusb_ca driver to the device. wusb_ca driver is a 
newly introduced driver for Cable Association only. It is a normal wired 
USB driver developed on wired USB driver API, fully compliant to Solaris 
USB framework.
4. User run wusbadm tool to specify with which WUSB host the device 
should be associated.
5. wusbadm tool sends a request to wusbd, who will then open the device 
node created by wusb_ca USB driver.
6. wusbd talk to the device via wusb_ca driver to create a CC. It then 
store the CC to CC database in file system, in the mean while, it loads 
the CC to the WUSB host driver.
7. wusbd then complete the association request from wusbadm tool.
8. Association is done. User then unplug the device. wusba_ca driver is 
then dettached.

After the above is done, user can then turn on the device radio to 
connect the WUSB device with host over air. The subsequent wireless 
enumeration is the same as wired USB. A newly introduced WUSB host 
driver (e.g., whci) is developer on the existing Solaris USB framework 
(usba). whci driver gets the device radio signal and consider it as a 
device plug event. It passes the event to usba framework module, the 
latter then load an existing USB device driver (e.g. usbprn(7D) if the 
device is a WUSB printer) to attach to the WUSB device.

If user reboot the system, wusbd daemon will load the CCs stored in the 
CC database to WUSB host driver instances. So that WUSB host can be 
ready to connect the associated devices.

Please note that, it is necessary to have a daemon (wusbd) because the 
daemon can load CCs to WUSB host drivers automatically after system 
reboot. Users want the WUSB device just work after each reboot, instead 
of manually running a tool to load CCs.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It seems that the functionality of wusbd is triggered in two cases:

1) By an explicit request from wusbadm, during the initial WUSB context
    creation process.
2) Automatically at bootup, to load the CC's into host drivers.

So, is a new daemon really needed?  It seems that the functions of
wusbd used in (1) above could be implemented in the wusbadm program
itself, and (2) above could be accomplished by a transient SMF service
that invokes wusbadm again with correct options.  I think the coreadm
service (svc:/system/coreadm:default) is a good example of this model.

  </pre>
</blockquote>
Sorry that I didn't mention another case that WUSB needs a daemon. The
WUSB industry has a kind of hotpluggable WUSB host, it is a USB2.0
dangle called HWA (Host Wire Adapter). When a HWA device is plugged,
the hwahc driver, which is developed on usba driver API, will attach to
it. But, before it is ready to connect WUSB devices, there must be a
daemon to load the CCs to the hwahc driver instance after the HWA plug
event. So, besides case (2) above, the wusbd daemon also needs to
listen to the HWA plug event and load the corresponding CCs to the
hwahc driver instance. <br>
<br>
Another consideration about the daemon is, the action of loading CC
should be something opaque to end users. It should just work
automatically and should not appear in the command line interface.
Please note that WUSB is mainly for desktop/laptop users. We have to
have an interface design which is easy for end users.<br>
<br>
Thanks,<br>
Colin<br>
</body>
</html>


_______________________________________________
security-discuss mailing list
security-discuss@opensolaris.org

[prev in list] [next in list] [prev in thread] [next in thread]