Hi... I fail to perceive the dire security risks you warn of. DFB requires access to your framebuffer, any attacker that really wants to should be able to hang your system by abusing the framebuffer badly enough. That's true the moment you let them run DFB apps, regardless of keyboard input.
I think the issue is more to do with TTYs -> why not start your DFB app in the background, that way you'll keep the tty of the vt you start it on? Ctrl-C won't be an issue... If you really need to write a stdin input driver, take a look at the inputdrivers/keyboard directory of the DirectFB source. A quick glance shows that while this level of the driver architecture does not look too complicated, adapting it to stdin may not be that easy -> DirectFB consumes keyboard events at a low level -> ie if you hit only the right-windows-key on your keyboard, DirectFB will register this as a keyboard event. I'm not sure a tty, even if you put it in raw mode, will ever give you a character if you press only the right-windows-key. And there will be a bunch of keys like this. You may find that it will not be that easy to pass the keyboard events into DirectFB in the correct way if all you get are tty-legal characters and control symbols. Also don't forget some applications react to a combination of keyboard and mouse input (shift-click, ctrl-drag or whatever), so these keyboard events are needed for normal operation. I think there are good reasons to read the keyboard the way it is done, and no real reasons to use stdin. I think you are a little unreasonable in your demands: after all, in your description of your crash you explicitly Ctrl-Z the DFB app to use its terminal. That means you put the app to sleep, it seems only reasonable to me that it not process any keyboard input in this situation. I would expect the same behaviour if you managed to Ctrl-Z the agetty process for a given VT. Richard Unger -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von user3545 . Gesendet: Montag, 14. November 2005 21:53 An: [email protected] Betreff: Re: [directfb-dev] Keyboard input driver related bug. X11 does lots of things - many of them I find to be unacceptable, this is entirely irrelevant. The crash was simply demonstrative of my point, as a result of an accident my system was made unresponsive. If it did not forcefully take control of my keyboard it would have been recovable. Regardless of the fact that when I execute my web-browser (links) and attempt to close it my system becomes unresponsive - this method of keyboard input is simply unacceptable to me due to the security implications of giving my web-browser full control of all input/output to/from my system. If that application is compromised it could simply emulate the application crashing to -> my terminal, a getty, the system dropping to single user mode and many other situations where sensitive information has to be provided to the system - not to mention effectively DoS the system from a non-root user. In YOUR opinion having keyboard input to the program using the standard unix streams may be the wrong solution. In MY opinion the wrong solution here is the one implemented - on numerous occasions it has resulted in my system becoming unresponsive, it is unstable, insecure and no where near the standard that one expects from release quality code. I am not asking you to change dfb, nor am I even asking you to write any actual code here - simply provide informal documentation to what the requirements for a keyboard input driver are so I can have a working system once more. --- Mike Emmel <[EMAIL PROTECTED]> wrote: > First X11 does the same thing that DirectFB does. > I think you need to switch VT first in code then > execute DirectFB ? > Or you need to unlink from the controlling terminal > ? > In any case there is nothing wrong with DirectFB > running its VT in raw mode. > The problem here is that you keep forcing the wrong > solution. > Go look at the X11 code start a X server and do the > same thing. > I bet it will hang you just as badly. > Type X -help do the keeptty and see. I don't think > its up to DirectFB > to detach from the controlling terminal by default > let your app. > > Mike > > > > On 11/13/05, user3545 . <[EMAIL PROTECTED]> > wrote: > > While using a DirectFB application, having it > allocate > > a vt, I switched back to the tty I executed it > from > > and backgrounded it so as to execute another > command. > > Forgetting to foreground it, switching to another > > terminal and then to the vt it had allocated - I > have > > just been greeted with a blank screen and a once > again > > unresponsive system. > > > > Normally I would have simply been able to switch > back > > to that console (with a blank fb) and then > foreground > > it - however due to how ANAL the keyboard input > driver > > is in its mission to steal all input to my system, > > this is not a posibility - hard reboot #(i forget > > already). > > > > Once again, if the relevant individuals are not > > willing to spend the time interfacing STANDARD > input > > to their own input library, could somebody please > > outline the functions required to do so. > > > > I appologise if this comes across as blunt however > > this is not the only issue I am currently > attempting > > to resolve and this is really beginning to piss me > off. > > > > > > > > > ___________________________________________________________ > > To help you stay safe and secure online, we've > developed the all new Yahoo! Security Centre. > http://uk.security.yahoo.com > > > > _______________________________________________ > > directfb-dev mailing list > > [email protected] > > > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > ___________________________________________________________ Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/ _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
