I'd like to summarize the request or benefit of this pair of ioctls.
1. Switching from Xorg to console while Xorg is running as a non-root
user. Of course we can seteuid() to root, close the input devices
and reopen them with root euid again while switching back to Xorg.
The thing is the handling of VT switching in xfree86 level of Xorg
(not down to Solaris level yet) *disables* the input devices instead
of closing them. If we were to adopt the close/reopen way, we need
to add Solaris specific code to the xfree86 level which seems ugly
to me and does not align with the handling of other OSes. Since
the upstream is the Xorg community, the better we make our changes
in Solaris specific level the better.
Plus, not setting euid to root again reduces the risk of potential
security attacks.
2. When we are back on console, Xorg is still listening to HAL.
If a keyboard is hooked up, Xorg will get the hotplug inform
from HAL and thus will open the keyboard via its hid nodes.
This would cause the input routed to the external stream even
if we are on the console now. Without the ioctl, the keyboard
will not be usable until we switch to Xorg. It could be reproduced
on my prototype of Xorg vt support.
Maybe the Xorg can ignore the input device hotplugging information
while on console, and query the info again upon switching back.
But this would involve deciding which input devices are old and
which are newly plugged. Complex.
3. hid device driver maintains 2 streams, ioctls to control the
routing of input between these 2 streams seems to be a natural
thing. If we can save the above complexities with these 2 simple
ioctls and accomplish a desirable clear architecture, why not?
The above are what I could think of till now.
Regards,
Aaron
On 06/03/09 08:46, Aaron Zang wrote:
> Actually this case is not with the intention to fix the hotplugged
> devices bug.
> Yes, Xorg needs to seteuid(0) back to open the newly plugged devices.
> But for the existing devices which are already opened, would it be
> easier and
> better to just send down a ioctl to switch streams than closing them on
> switching
> away and opening them upon switching back with seteuid(0)?
>
> I was just following the idea of KIOCSDIRECT ioctl, and at least to me, the
> shorter of time an application is running with euid 0 the better.
>
>
> Regards,
> Aaron
>
>
> On 06/03/09 08:28, Alan Coopersmith wrote:
>> James Carlson wrote:
>>> Alan Coopersmith writes:
>>>> That's a bug that was just reported to me in private e-mail while I
>>>> was out on
>>>> vacation last week. We need to fix Xorg to setuid back to root
>>>> before opening
>>>> hotplugged devices.
>>> So ... with that bug fixed, does the need for this special ioctl
>>> remain? Doesn't closing the descriptor and reopening it when needed
>>> fix the problem?
>>
>> Now that I've had a chance to look at it and not just read the e-mail,
>> I'm
>> trying to determine if that is the correct fix or if the bug is in the
>> kernel
>> side. The devices are owned by the uid Xorg is running as, due to
>> logindevperms, but it seems additional privileges are being required
>> by the
>> kernel drivers (PRIV_SYS_DEVICES) - if it's correct for them to
>> require that,
>> then I'll work on fixing Xorg to seteuid(0) there. (Xorg has not
>> been made
>> privilege aware so far since the two states it has needed in the past
>> are "all privileges" during server/device initialization, and the
>> basic set
>> provided by seteuid to a non-root user during most of runtime, so
>> there was no
>> benefit in adding privilege awareness to the code.)
>>
>> I was not involved in the decision to create this ioctl, so I can't
>> answer
>> their motivations or why the project team decided creating an ioctl was
>> better than adding an additional spot for Xorg to return to uid 0.
>>
>
--
You know some birds are not meant to be caged, their feathers are just too
bright.
????????????????????????
