Forgetting to foreground the application was an accident, one I just repeated.
The issue is not that it is ignoring keyboard input, but that it is requesting that all input to the system be sent to it and then when backgrounded, ignoring it. That is the least of my concerns. This is simply a demonstration of the fact that if the application crashes then the system has effectively done the same.
Denial of Service is far from my concerns of security. These concerns have been listed and ignored - I see no reason to repeat myself.
I am fairly certain that when agetty is backgrounded, one can still switch terminals and one does not have to hard reboot the system to regain control of it locally.
As getting stdin to work with this library is clearly going to be one right royal hack, it seems simplier that I find some alternative to DFB. I wish you all luck in ignoring perfectly tangable security vulnerabilities and writing further unstable code.
*big sigh*
Unger Richard <[EMAIL PROTECTED]> wrote:
The issue is not that it is ignoring keyboard input, but that it is requesting that all input to the system be sent to it and then when backgrounded, ignoring it. That is the least of my concerns. This is simply a demonstration of the fact that if the application crashes then the system has effectively done the same.
Denial of Service is far from my concerns of security. These concerns have been listed and ignored - I see no reason to repeat myself.
I am fairly certain that when agetty is backgrounded, one can still switch terminals and one does not have to hard reboot the system to regain control of it locally.
As getting stdin to work with this library is clearly going to be one right royal hack, it seems simplier that I find some alternative to DFB. I wish you all luck in ignoring perfectly tangable security vulnerabilities and writing further unstable code.
*big sigh*
Unger Richard <[EMAIL PROTECTED]> wrote:
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 Emmelwrote:
> 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 .
> 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
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
_______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
