Folks, Please review the following investigation results. Any comments are welcomed.
gw-1 How does this play with devkit, device allocation, SunRay? All the above are investigated. They are out of scope of this project and there are no conflicts. Details see following: - devkit: It is being ported to Solaris and is similar as HAL regarding as functionality and interface dependencies. It is a userland utility which is going to depend on libdevinfo and libsysevent. It gets device information from libdevinfo and listens to sysevents for device add/remove events. This project does not break the existing interfaces which devkit will depend on. I've talked to the devkit team and confirmed this. - device allocation: It "manages the ownership of devices". It depends on devfs interfaces. This project implements hotplug controller drivers and framework which are in the kernel device driver level which is under devfs. So it does not impacts device allocation. The userland administer tool introduced by this project is used to issue commands to kernel drivers to hot add/remove devices to/from the "system". It is not related with user ownerships. And the tool will conform to RBAC, so only a user with proper authorizations can issue commands to hotplug devices to/from the system. This prevents the tool from conflicting/breaking device allocation. - SunRay: Sun Ray client is not related. Sun Ray server is a userland application which can run on Solaris and Linux. It manages remote devices on Sun Ray clients including hotplug operations. However, Sun Ray server is an independent userland application which does not interact with Solaris hotplug framework or device drivers. For example, if a usb keyboard is plugged to a Sun Ray client, the Sun Ray server gets the event from network and starts a userland process to deal with the hotplug event. And then a Sun Ray specific userland usb device driver works for the device. Sun Ray support is out of scope of this Solaris project. gw-2 This project seems to require administrative audit, yet there is no mention. See the 20 Questions (and Solaris Audit Policy). In scope. The project team will address it in commitment documents. gw-3 What is the method context for the service? Are there any properties? Is this enabled by the profile? Is there any reason to ever disable it manually? In scope. The project team will address it in commitment documents. gw-4 Root is not a privilege (nor is uid 0 special) why isn't this authorization driven? Just how are you doing access control? Access control decisions also require audit. The project team will turn to RBAC in commitment documents. gw-5 I'm dubious about the Patch binding. Verify with the Solaris Evaluations and Trusted Extensions project teams that this is appropriate for a Patch. The manager is Craig Payne. Hotpug project team sent emails to Craig for this issue but did not get any responses. The following are the investigation results from hotplug project team on this issue: There are mainly two parts of this project, one is to implement hotplug controller drivers and framework in the kernel device driver level; another is the userland administer tool to issue commands to the kernel drivers to initiate the operation of hot add/remove device to/from the system. All these jobs are not directly related with "Solaris Evaluations and Trusted Extensions project". Our userland administer tool will conform to RBAC, so that only users with proper authorizations can perform the device hotplug operations for a system. Given these, we didn't see any risks that our project would break "Solaris Evaluations and Trusted Extensions project". And, for a reference of the existing stuff, cfgadm(1M) is the existing framework which does the similar functionality. It co-exists with TX for many years. gw-6 What would be the meaning of "remote clients". INET sockets should be avoided as they add an attack vector. I'm still dubious about doors being complex. The project team will turn to door in commitment documents. gw-7 What is the compelling reason that RBAC must be postponed? How is the project complete without meeting the Solaris Policies? Is a PAC waver going to be requested? RBAC will be supported. The project team will address it in commitment documents. Thanks, Colin
