Re: Supporting multiple keyboard

[Petr V. <VAN...@vc...>]

On  8 Jun 00 at 9:51, James Simmons wrote:
> > Are you sure that it is so big security hole? 

> Yes :( Remeber the video memeory is shared with all VCs allocated to it.
> Each VC has it own text buffer which make sit safe to have different apps
> writing on different VCs at the same time. Any changes the frmaebuffer
> mapping makes effects all the VCs attached to it. A good example is I use
> Mesa-GGI and when I VT switch it works right. By if I VT switch back and
> forth very rapily it locks my machine. The text buffer and framebuffer 
> contents get scrambled. 

Locking machine is not security hole... It is bad bug in software...
 
> > You started processes on
> > both VT's, if you were allowed to switch them... 
> 
> This is no problem if both process are text console programs since they
> have seperate text buffers. 

If they are graphics programs, they must either explicitly disable switching
or they must be able to handle switches correctly.
 
> > Oops, there is special
> > case when you have syslog printing output to screen... 
> 
> While in graphics mode printk or syslog could still write to the text
> buffers instead of directly to the video memory. You also have the power
> of redirect. You can even send it to your printer.

I was talking only about security... That if you mmap /dev/fb and switch
to syslog screen, you can get these data. It is not possible through 
/dev/vcsa, as this can be controlled per-VT.

> > But oops again,
> > there is only one difference - without mmapping /dev/fb YOU have to
> > read screen and write it down, with /dev/fb software can do it for you...
> 
> I though /dev/vcsa was for that. 

/dev/vcsa* is per VT (and I hope that /dev/vcsa is process's VT and not
foreground VT), so you cannot steal information through this. But you can
through /dev/fb.

> > XF68_FBDev worked only with raw->mediumraw patch in XFree 3.3.x...
> 
> Its going to have to be patched anyways to use /dev/input/*
> 
I'd like to see some backward compatibility in picture. Until last month
platan.vc.cvut.cz was still running '95s Slackware 3.0 (with couple of
new things, such as glibc and kernel 2.3.33, but X was still old, non-matrox
aware version).
                                    Best regards,
                                            Petr Vandrovec
                                            van...@vc...