Ben Barrett wrote: > 1. I never realized that 'xkill' could pass the appropriate signals through > a remote Xwindows connection, which in my case was SSH-tunnelled. If anyone > has explored this or knows more, I'm very curious, about the security > implications, for instance; what can you tell me? Example: you log your > buddy into their remote account as they borrow your system momentarily, they > do their stuff, but could easily (accidentally or otherwise) kill anything > on your desktop, or possibly the entire session(?). I know they could close > anything, having physical access, but I feel like I'm not getting the whole > picture.
X is a network-transparent window system. That means that it doesn't matter whether there is a network between the client and the server. The client has exactly the same privileges and capabilities in either case. There is at least one exception in the X11 protocol, the one that I can remember is that the "xhost" command only works through a local connection. But you can do nearly everything remotely that you can do locally. Linux Terminal Servers rely on that. Some of the things a client (any client) can do include: reading any part of the screen or offscreen pixmaps, reading or changing any window's properties, and reading events from the mouse and keyboard (e.g., keystroke logging). I'm sure you can see what the security implications are -- if you're going to run an X client on a host, your workstation, and other hosts that also run X clients on it, are no more secure than that host. > 2. File handle review: open an editor on a file, suspend that, move the > file or delete it, resume and quit the edit. Does the move or delete hold > onto the previously-opened filehandle, and wait (in the background, as the > mv or rm appear to return true) with its operation queued until the release > from the edit? Try it and see. I just tried it with emacs and vi, so I know what those two editors do. (-: For more understanding, use strace to see the sequence of system calls each program uses. > 3. How do you (subjectively) weigh the benefits of a mini-itx system for a > home entertainment PC, versus a mini-P4? Obviously, the P4 sucks more power > and can have far more processing power -- and can also be made nearly as > quiet. The mobo/cpu combo's I'm looking at cost about the same... I'm just > looking for the variety of people's opinions here, offer whatever you care > to. Video comes in many formats. I doubt a VIA CPU can handle realtime decompression of most of those formats. And future codecs will be more compute intensive. If you're building a single-purpose box that only uses MPEG compression, and you can get the hardware MPEG decoder to fly, the VIA boards might be suitable. -- Bob Miller K<bob> kbobsoft software consulting http://kbobsoft.com [EMAIL PROTECTED] _______________________________________________ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
