James Carlson wrote: > Lei Chen writes: > >> I'm working on a USB project. This project is going to deliver an SMF >> service which spawns a daemon process to manage USB devices in the system. >> The daemon characteristic and USB hotplugable nature cause some problems. >> > > Is this something separate from devfsadmd? Should it be? > In fact, this daemon is used to handle wireless USB device connection context, while the devfsadmd manages reconfiguration and device dynamic events. The new daemon needs to interact with WUSB host to setup a wireless USB device's connection context. The interactions between daemon and host are through ioctl.
> >> USB device drivers exports their device nodes as owned by root user with >> permission set to 644. This means only root can do ioctl on the device nodes. >> > > That doesn't seem correct. Device node permissions are checked only > at open(2) time. They have nothing to do with ioctl(2). > > In fact, the device node doesn't even have to exist at all for > ioctl(2) to work correctly, and I see nothing that requires write > permissions in order to do ioctls. > > Am I missing something? Have you tried this and failed? > Thank you for the reminding. I had taken it for granted that ioctl needs write permission. Yes, as long as the user can open the device even only with O_RDONLY mode, the ioclt can also be done on it. This might be an issue for a wireless USB host device. The drv_priv(9F) should be used to check application's privilege to prevent any user with only read permissions from stopping a host device. > >> I know in a daemon process, all needed files and devices can be >> opened before set itself to daemon user and remove some privileges, then the >> process can still access(write) those opened files/devices as daemon user. >> But for a USB device, it can be hotplugged at anytime. If the daemon process >> has been started and set to daemon user, then it can not do ioctl on the >> newly added USB device even if it can open that device node. That's the >> problem, since some USB device will act as host to connect with other USB >> devices. For security reasons, the USB host device node can't be writable >> worldwide. >> > > If you need to run as root, then do so, and limit the privileges you > use to exactly the ones you require. > > It's unclear, though, what the correct permissions should be and what > those permissions have to do with this daemon. > It seems clear now that we can run the daemon process as daemon user with proper privileges preserved. Thanks a lot, Lei Chen
