What I'm really concerned about is: I don't like the idea of running things SUID (especially games). I know very little about X and programming and was just wondering if this will ever be "fixed"?
Otherwise, game developers will be forced to be root just to make games (unrealistic on multiuser systems). And if the game isn't written well, SUID will leave users with a glaring security problem. IMHO, this SUID issue must be "fixed" soon. Thanks, pesarif On Fri, 11 Jan 2002 05:23, Derrik Pates wrote: > Sorry if this is a "sort-of-repeat", I thought I sent it. > > On Thu, 10 Jan 2002, Billy Biggs wrote: > > 1. We don't have kernel-level video drivers, so we can't safely mmap > > to a user app sections of video memory. > > Right. > > > 2. Giving a user full access to the framebuffer is dangerous so only > > let root do it. > > Sort of. In theory, it could be made sufficiently safe (that's what the > GGI crew wanted to do with KGI). > > > That is, there's no reason you need full access to /dev/mem just to > > write to the framebuffer, it's just some silliness because of the way > > everything is architectured. I'd love to find out the real reason > > though. > > If we had framebuffer drivers in the kernel for everything, it'd be OK > (then you just have to mediate access between X and the kernel framebuffer > driver). However, in the current situation, mapping /dev/mem is necessary. > Userspace processes don't know anything about the real physical addressing > of memory normally (and they don't have to care - the whole beauty of > virtual memory systems), allowing each process to kick around in its > littlee sandbox without bugging anybody else. However, to directly access > the framebuffer as it stands, via DGA, a process tells X it wants to do > DGA - then the X server tells it the framebuffer base address (an offset > into physical memory where the display device's framebuffer memory lives), > the size of it, and the line width. The process then opens /dev/mem, > mmap()s the framebuffer by offset and length. Unfortunately, allowing > access to /dev/mem opens us up to an untrusted program proceeding to > scribble on whatever it wants in system RAM. (Among all the other things > it can do as root.) Which is why you have to be picky about what programs > you make SUID root, of course. :) > > One good reason why the DirectFB project wouldn't be such a bad thing. > > Derrik Pates | Sysadmin, Douglas School | #linuxOS on EFnet > [EMAIL PROTECTED] | District (dsdk12.net) | #linuxOS on OPN _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
