Unfortunately, that isn't feasible, because VirtualGL relies upon Direct Rendering to handle most of the OpenGL commands. That's why VGL only intercepts GLX commands and a few OpenGL commands-- basically everything that's necessary to manage the redirecting of OpenGL contexts from the 2D X server to the 3D X server and from windows to Pbuffers, but nothing more. Once an OpenGL context has been redirected into a Pbuffer on the 3D X server, VirtualGL gets out of the way, and OpenGL commands pass through unimpeded until the frame has finished rendering. What you propose would require a full OpenGL interposer, which would be a maintenance nightmare given that OpenGL changes so frequently. Also, there's the matter of what to do with the OpenGL commands once they reach the hypothetical IPC server. Unless that IPC server was somehow in-process with the 3D X server, the IPC server would be limited in its ability to pass OpenGL commands to the 3D X server in much the same way that VirtualGL is limited. I made an active decision in 2004 not to create a full OpenGL interposer, for reasons described here: https://virtualgl.org/About/Background. If you did want to build such a solution, you'd be better off basing it on the Mesa source, since Mesa keeps track of changes in the OpenGL API and already provides dispatching mechanisms.
In general, the 3D X server in a VirtualGL server should be thought of as a shared resource, and it shouldn't be used for any security-conscious activities. If you need to use a local X server on the VirtualGL server, then I strongly recommend configuring two X servers-- one headless that is dedicated to VirtualGL and another one that can be used for local activities. In a VirtualGL environment, it doesn't really matter if an application takes over the keyboard and mouse on the 3D X server, because VirtualGL is only using the 3D X server to execute GLX commands. And VirtualGL is designed to run at the display manager login prompt, which prevents anyone from having unrestricted access to a local desktop. On 4/14/20 6:32 PM, Tom Li wrote: > Hello. > > I'm exploring possible methods to run OpenGL-enabled desktop > applications in > an isolated X server "sandbox", so that these applications cannot take > over > the main X server's mouse, keyboard, screen, etc, and have > unrestricted access > to the main's desktop and/or each other. > > Traditionally, Xephyr is the solution, and the procedures are basically: > (1) Run Xephyr in a seperate user, grant Xephyr permission to access > the main > X server to display itself as a window. (2) Run a GUI program is a > seperate > user, grant it permission to access Xephyr. Thus, the program can be > completed > isolated, but it does not support OpenGL, and not useful for 3D > applications. > So I turned to VirtualGL. > > Unfortunately, access to an 3D X server is required for VirtualGL to > work. And > since it's not possible to run multiple X servers on a single GPU, the > only > option is granting the access to the main X server to all > VirtualGL-powered > applications on the system. By doing so, the isolation between the main X > server and the isolated X server becomes non-existent. Programs inside the > sandbox will be able take control of the main X server. > > I wonder is it theortically possible to modify the codebase of > VirtualGL to > implement an additional privilege seperation? My basic idea is to > modify the > VirtualGL Faker - Instead of issuing OpenGL commands by accessing the 3D X > server itself, it only passes these commands to a server via IPC. Only the > Faker Server, running as a different user, has access to the 3D X > server. In > this way, a VirtualGL-powered 3D programs is completely seperated from the > main 3D X server, providing a sandboxed graphics environment. It's > also helpful > in a shared 3D server, since users will not be able to access each > other via > the 3D X server. > > Is this a good/feasible idea? If it's feasible, how difficult will the > implementation be? > > Thanks, > Tom Li > -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/be2caf5b-96d3-7bd4-ed41-58a14b178919%40virtualgl.org.
