![]() ![]() If the screen is locked, then this is how many seconds the password dialog box should be left on the screen before giving up (default 30 seconds). The default is 0, meaning that if locking is enabled, then a password will be required as soon as the screen blanks. But, if there was user activity at 15 minutes or later (that is, -lock-timeout minutes after activation) then a password would be required. If there was user activity at 12 minutes, no password would be required to un-blank the screen. For example, if this is 5, and -timeout is 10, then after 10 minutes, the screen would blank. If locking is enabled, this controls the length of the "grace period" between when the screensaver activates, and when the screen becomes locked. ( Note: this doesn’t work if the screensaver is launched by xdm(1) because it can’t know the user-id of the logged-in user. The running saver will be restarted every cycle minutes even when mode is one, since some savers tend to converge on a steady state.Įnable locking: before the screensaver will turn off, it will require you to type the password of the logged-in user (really, the person who ran xscreensaver), or the root password. Look for them in nf or whatever it is called. If your server is configured to load the RECORD, XTRAP or XTEST extensions, you absolutely should disable those, 100% of the time. These extensions are nominally for debugging and automation, but they are also security-circumventing keystroke loggers. Many distros enable by default several X11 server extensions that can be used to bypass grabs, and thus snoop on you while you’re typing your password. The strength of the lock on your front door doesn’t matter much so long as someone else in the house insists on leaving a key under the welcome mat. There’s little that I can do to make the screen locker be secure so long as the kernel and X11 developers are actively working against security like this. It shoots down random long-running programs of its choosing, and so might might target and kill xscreensaver, and there’s no way for xscreensaver to protect itself from that. This is the Linux kernel "OOM-killer" keystroke. You can disable it by turning off AllowClosedownGrabs in nf. This so-called "feature" showed up in the X server in 2008, and as of 2011, some vendors are shipping it turned on by default. This keystroke kills any X11 app that holds a lock, so typing this will kill xscreensaver and unlock the screen. There is no way to disable VT switching only when the screen is locked. ![]() You can disable VT switching globally and permanently by setting DontVTSwitch in your nf, but that might make your system harder to use, since VT switching is an actual useful feature. So don’t leave yourself logged in on other consoles. If you left a shell logged in on another virtual console, it is unprotected. These keystrokes will switch to a different virtual console, while leaving the console that X11 is running on locked. To disable this keystroke globally and permanently, you need to set the DontZap flag in your nf or XF86Config or XF86Config-4 file, depending which is in use on your system. ![]() If the user launched X11 manually, that text console will still be logged in. This keystroke kills the X server, and on some systems, leaves you at a text console. If you care about keeping your screen locked, this is a big problem. The XFree86 X server and the Linux kernel both trap certain magic keystrokes before X11 client programs ever see them. (It doesn’t even need to be fast 3D hardware: the problem will be fixed if there is any 3D hardware at all.) ![]() Your options are: don’t use the OpenGL display modes or, collect the spare change hidden under the cushions of your couch, and use it to buy a video card manufactured after 1998. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |