Darren J Moffat wrote: > LingBo Tang wrote: > >>Darren J Moffat wrote: >> >>>LingBo Tang wrote: >>> >>>>- current VT usage model is not match with devname as other cases, >>>> like pts and clearview; >>>>- manage active link as symlink in devname filesystem requests expand >>>> current devname. >>>>- VT daemon can update the contents of "active link" by two syscalls, >>>> which only have a very small time window for potential incorrect >>>> plug-in device accessing. >>> >>>very small ? >>> >>>No window of incorrectness is acceptable, since a race condition like >>>this could lead to possible incorrect permissions and this security >>>problems. >>> >>>It MUST always be correct, if you can't make it always correct don't >>>do it. >>> >> >>How about change the target of symlink as below? >> >>During VT switch, change the target to next target VT first, then >>do actual VT activate ioctl. > > > What happens then if the activate ioctl is interuptted or some how fails ? > > This needs to be atomic. > > >>if the target VT has no user login, ( in another words, login programs >>is using that VT, and the ownership of VT node is root ) then the >>worst case is the ownership of new plug-in device is set to "root". >>The user can do plug-out/plug-in again to solve the incorrect ownership >>for this case. > > > Having the user need to plug and unplug things to fix problems in our > architecture isn't aceptable. > > >>If there has been user login on target VT, the plug-in device will >>belong to that user. >> >>Because switching VT and changing target of symlink are 2 operations, >>how to make it work in synchronization way? > > > It is only to operations because your implementation is making it that > way. It needs to be an atomic operation or you need to drop the active > symlink concept. Maybe a symlink is the wrong implementation. Maybe > the kernel subsystem when it does the switch should be updating the > active node (ie it isn't actually a symlink but a different name for > /dev/vt/#). > > >
devfsadmd(1M) will retrieve the uid/gid from console tty, i.e. /dev/vt/active, for plug-in devices by stat(2). Any other type will require changing current implementation of devfsadmd. Regards, LingBo