Hi DRC, Thanks a lot for your response.
> > (1) If a user is logged in remotely and is using VirtualGL, that means > they have access to display :0. Thus, they can theoretically snoop the > keystrokes or view the desktop of someone who is logged in locally to > the machine. Solution? Don't log in locally using the X server, unless > you are sure no one is on the machine. The only one who should ever > need to log in locally is the SysAdmin, and they can administer the > machine using VNC or SSH or remote X or the local text console. In > fact, switching to the local text console will disable anyone's ability > to use display :0 with VirtualGL, so this effectively turns off > VirtualGL use temporarily. So if two user are using display :0 at the same time (is that possible? e.g. user1 has a MatLab open and user2 has a blender open, both using vglconnect), they can in theory snoop each other's keystrokes? The machine will be locked up in the racks, so no one will be using the local X. As long as users can't get each other's password by logging keystrokes, it should be fine. Thanks -Yushu > > (2) A VirtualGL user can theoretically snoop the 3D rendering commands > and rendered 3D images being transferred between other users' > applications and display :0. In the past, some ultra-paranoid users, > such as application service providers that had multiple companies > sharing the same machine, saw this as a problem, but those problems are > largely solved through virtualization these days. If all of the > VirtualGL users work for the same organization and there are thus no IP > concerns regarding the rendered 3D images, then this is a non-issue. > > > It is the case that any user who has access to any X server can log > events being sent to that X server or view the output of the X server. > That's simply the way X11 works. It has nothing to do with VirtualGL > specifically, except that we are having to go through the X server to > get access to the 3D hardware. Sun did some work regarding direct 3D > hardware access on SPARC, using an API called GLP, and we tried to get > vendors interested in using the EGL API > (http://www.khronos.org/registry/egl/) for doing the same thing on x86 > platforms, but unfortunately, no one seems to be interested in this. > Thus, we have to jump through some hoops to access the root X server in > as secure a manner as possible. > > > Restricting access to vglusers is mainly useful if you are in a less > controlled IT environment, in which many users will be logging into the > machine but not all will be using VirtualGL. It just gives you a way of > knowing who has access to your root X server. However, if most users in > your organization will be using VirtualGL, there is no benefit to using > the vglusers restriction. > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
