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

Reply via email to