[gentoo-user] Re: escape from i3lock
On 2019-07-12, Ian Zimmerman wrote: > On 2019-07-11 21:28, Nuno Silva wrote: > >> vlock -n -a > > Does vlock work from an XWindow session? Or would I have to use it on > top of whatever I do to lock the XWindow session - xscreensaver/i3lock > etc? It does work from inside X11 here. I can, for example, run it inside a terminal emulator or through the window manager. (You will probably need to add your user to the "vlock" group.) > (I browsed to the vlock README page on github but it doesn't answer this > question.) -- Nuno Silva
Re: [gentoo-user] Re: escape from i3lock
On Fri, 2019-07-12 at 09:01 -0700, Ian Zimmerman wrote: > On 2019-07-11 21:28, Nuno Silva wrote: > > > vlock -n -a > > Does vlock work from an XWindow session? Or would I have to use it > on > top of whatever I do to lock the XWindow session - > xscreensaver/i3lock > etc? > > (I browsed to the vlock README page on github but it doesn't answer > this > question.) > vlock -a is supposed to lock all virtual consoles. The -n makes it create a new vt, so it'll work even from within a running X session and it seems to block the ability to switch back to the X session until the system is unlocked. But -n also requires root privileges. Might also want to throw in a -s to temporarily disable alt-sysrq. This can basically take the place of your current screen locker and does a better job than even xscreensaver of locking out the system. signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] Re: escape from i3lock
I think it can only be started from a VT. But what's the problem? I have an xsession going, plus tmux, plus perhaps something else going in one or more VT All I have to do is call vlock -a from a virtual terminal. Now to access any terminal VT or xsession - you have to unlock this VT first. But I can still access my box remotely through SSH Il Ven 12 Lug 2019, 18:01 Ian Zimmerman ha scritto: > On 2019-07-11 21:28, Nuno Silva wrote: > > > vlock -n -a > > Does vlock work from an XWindow session? Or would I have to use it on > top of whatever I do to lock the XWindow session - xscreensaver/i3lock > etc? > > (I browsed to the vlock README page on github but it doesn't answer this > question.) > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > To reply privately _only_ on Usenet and on broken lists > which rewrite From, fetch the TXT record for no-use.mooo.com. > >
[gentoo-user] Re: escape from i3lock
On 2019-07-11 21:28, Nuno Silva wrote: > vlock -n -a Does vlock work from an XWindow session? Or would I have to use it on top of whatever I do to lock the XWindow session - xscreensaver/i3lock etc? (I browsed to the vlock README page on github but it doesn't answer this question.) -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Re: escape from i3lock
I've been using vlock -a for years ... it works. Il giorno ven 12 lug 2019 alle ore 03:18 Laurence Perkins < lperk...@openeye.net> ha scritto: > > > So the solution is to just use "xscreensaver" by jwz. Which can be > > configured to just blank the screen etc. as wanted by the op. See > > also > > the FAQ: https://www.jwz.org/xscreensaver/faq.html > > > > HTH, > > -dnh > > > > Except I use xscreensaver myself and it in no way prevents VT switch, > which is what the OP was hoping to find a way to do if and only if the > screen is locked. Programs that grab input still don't get to block > combos that are processed by the X server before they even get to the > program's input queue any more than grabbing input will block the alt- > sysrq kernel-level interrupt keys. > > Disabling VT switch by the X server and then setting up some other way > to trigger a switch that will be blocked by whatever screen locking > program the OP wishes to use is the best solution I can think of. chvt > would be the program to call. Whether he wants it to be a keyboard > shortcut handled by his DE or some other trigger method is a matter of > taste. > > LMP >
Re: [gentoo-user] Re: escape from i3lock
> So the solution is to just use "xscreensaver" by jwz. Which can be > configured to just blank the screen etc. as wanted by the op. See > also > the FAQ: https://www.jwz.org/xscreensaver/faq.html > > HTH, > -dnh > Except I use xscreensaver myself and it in no way prevents VT switch, which is what the OP was hoping to find a way to do if and only if the screen is locked. Programs that grab input still don't get to block combos that are processed by the X server before they even get to the program's input queue any more than grabbing input will block the alt- sysrq kernel-level interrupt keys. Disabling VT switch by the X server and then setting up some other way to trigger a switch that will be blocked by whatever screen locking program the OP wishes to use is the best solution I can think of. chvt would be the program to call. Whether he wants it to be a keyboard shortcut handled by his DE or some other trigger method is a matter of taste. LMP signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] Re: escape from i3lock
Hello, On Thu, 11 Jul 2019, Laurence Perkins wrote: >You could also leave DontVTSwitch on all the time and set a keyboard >shortcut to run chvt (man 1 chvt) with appropriate permissions and >parameters instead. Keyboard shortcuts shouldn't get processed if the >screen is locked. The screensaver has to get _and keep_ the lock on input. The sad thing is, people do needless rewrites and get it wrong again and again and again, despite jwz' xscreensaver code from 1991 on, setting an example on how to do it right... Cue gnome-screensaver, the kde stuff, apparently also i3lock etc.pp. ad nauseam, all repeating the very bugs jwz wrote about in 2004 (the toolkits.html)... VT Switching is just a little subclass of the underlying problems of those "lock screen" programs that don't lock your screen. https://www.jwz.org/xscreensaver/toolkits.html / Epilogue I wrote this document in 2004, explaining the approach to privilege separation that xscreensaver has taken since 1991. Of course, the people doing needless rewrites of xscreensaver have ignored it for that whole time, and have then gone on to introduce exactly the bug that I described in this document as a hypothetical strawman! And -- this would be hilarious if it weren't so sad -- have introduced it multiple times. As I said in 2015: If you are not running xscreensaver on Linux, then it is safe to assume that your screen does not lock. Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. (read the whole thing linked document!). Also: https://www.jwz.org/xscreensaver/man1.html#8 https://www.jwz.org/blog/2014/04/the-awful-thing-about-getting-it-right-the-first-time-is-that-nobody-realizes-how-hard-it-was/ https://www.jwz.org/blog/2015/04/i-told-you-so-again/ (also follow the "previous" links ;) So the solution is to just use "xscreensaver" by jwz. Which can be configured to just blank the screen etc. as wanted by the op. See also the FAQ: https://www.jwz.org/xscreensaver/faq.html HTH, -dnh -- "Humans need fantasy .. to *be* human" -- Death (in Hogfather)
Re: [gentoo-user] Re: escape from i3lock
You could also leave DontVTSwitch on all the time and set a keyboard shortcut to run chvt (man 1 chvt) with appropriate permissions and parameters instead. Keyboard shortcuts shouldn't get processed if the screen is locked. LMP On Thu, 2019-07-11 at 21:01 +, artur.tamm...@gmail.com wrote: > I tried to google if it is possible to change xorg serverflags in > runtime, > but was unable to find anything. I think that would be a cleaner > solution > (changing the DontVTSwitch option before locking and then restoring > later). > > Artur > > Ian Zimmerman writes: > > > On 2019-07-11 09:57, Ian Zimmerman wrote: > > > > > > setxkbmap -option srvrkeys:none > > > > i3lock -c 003355 -n > > > > setxkbmap -option '' > > > > > > Thanks for the idea! It won't work as is for me because I > > > already use > > > some non-default xkb options. But it is closer than anything > > > that has > > > come up yet. I'll get there. > > > > Okay, I got it to work in a brute force way: I just added another > > setxkbmap command to set my normal options, the same ones as in my > > xorg.conf. > > > > But something weird happens when I try the fancy way: saving the > > options > > with "setxkbmap -print >FILE" and then restoring them with "xkbcomp > > FILE". It seems that the change I make with "setxkbmap -option > > FOO" is > > never reflected in the output of "setxkbmap -print". > > > > Looks like another place with multiple "levels" of configuration > > stepping over each other. > > > > -- > > Please don't Cc: me privately on mailing lists and Usenet, > > if you also post the followup to the list or newsgroup. > > To reply privately _only_ on Usenet and on broken lists > > which rewrite From, fetch the TXT record for no-use.mooo.com. > > signature.asc Description: This is a digitally signed message part
[gentoo-user] Re: escape from i3lock
I tried to google if it is possible to change xorg serverflags in runtime, but was unable to find anything. I think that would be a cleaner solution (changing the DontVTSwitch option before locking and then restoring later). Artur Ian Zimmerman writes: On 2019-07-11 09:57, Ian Zimmerman wrote: > > setxkbmap -option srvrkeys:none > > i3lock -c 003355 -n > > setxkbmap -option '' > > Thanks for the idea! It won't work as is for me because I already use > some non-default xkb options. But it is closer than anything that has > come up yet. I'll get there. Okay, I got it to work in a brute force way: I just added another setxkbmap command to set my normal options, the same ones as in my xorg.conf. But something weird happens when I try the fancy way: saving the options with "setxkbmap -print >FILE" and then restoring them with "xkbcomp FILE". It seems that the change I make with "setxkbmap -option FOO" is never reflected in the output of "setxkbmap -print". Looks like another place with multiple "levels" of configuration stepping over each other. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
On 2019-07-11 09:57, Ian Zimmerman wrote: > > setxkbmap -option srvrkeys:none > > i3lock -c 003355 -n > > setxkbmap -option '' > > Thanks for the idea! It won't work as is for me because I already use > some non-default xkb options. But it is closer than anything that has > come up yet. I'll get there. Okay, I got it to work in a brute force way: I just added another setxkbmap command to set my normal options, the same ones as in my xorg.conf. But something weird happens when I try the fancy way: saving the options with "setxkbmap -print >FILE" and then restoring them with "xkbcomp FILE". It seems that the change I make with "setxkbmap -option FOO" is never reflected in the output of "setxkbmap -print". Looks like another place with multiple "levels" of configuration stepping over each other. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
On 2019-07-10, François-Xavier CARTON wrote: > On 7/10/19 7:03 PM, Ian Zimmerman wrote: >> Here is my next "low information" question, haha. >> >> I use i3lock which is like Xscreensaver but much much simpler; it plays >> no movies or games, just blanks the screen with a configured color or >> image. To unlock it you have to type your password. >> >> It bothers me that even when i3lock has locked the X session, I can >> still switch to other Linux virtual consoles with Alt-Control-F , >> without typing the password. It so happens that on one of the other >> virtual consoles there is often an interactive root shell :-P >> >> So, is it possible to prevent virtual console switching while the X >> screen is locked, but still allow it at other times? Looks like >> something the locker program would have to do, not the X server; but >> again I don't know much about this stuff. >> > > Not a direct answer to your question, but as a workaround you can use > tmux sessions, and simply detach them and logout when you lock your > computer. > > Also, if this is just a shell to start the X server, you can launch it > as "startx & bg; disown" and then logout. > Another workaround: If you can't find a better solution, give vlock a try: vlock -n -a -- Nuno Silva
[gentoo-user] Re: escape from i3lock
On 2019-07-10 23:46, artur.tamm...@gmail.com wrote: > #!/bin/bash > setxkbmap -option srvrkeys:none > i3lock -c 003355 -n > setxkbmap -option '' Thanks for the idea! It won't work as is for me because I already use some non-default xkb options. But it is closer than anything that has come up yet. I'll get there. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
On 2019-07-11 10:43, Adam Carter wrote: > > No, it's my way to run things as root, in general. I distrust su, sudo > > and friends. > > > > su is mature, well understood and the standard way of doing things. If you > had run an extra term in your X session that had been su'd to root, you > wouldn't be exposing a root shell at the console. Perhaps your distrust of > su is making you less secure? You might be thinking in absolutes, eg "su > is insecure" but its better to think along the lines of "is > more or less secure than su?" I have specific reason for the distrust [1]. Your argument regarding _relative_ security is well taken. But I still feel that having the root shell outside of my X session would be more secure, providing I close the switching hole. [1] https://www.openwall.com/lists/owl-users/2004/10/20/6 -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Re: escape from i3lock
> No, it's my way to run things as root, in general. I distrust su, sudo > and friends. > su is mature, well understood and the standard way of doing things. If you had run an extra term in your X session that had been su'd to root, you wouldn't be exposing a root shell at the console. Perhaps your distrust of su is making you less secure? You might be thinking in absolutes, eg "su is insecure" but its better to think along the lines of "is more or less secure than su?"
[gentoo-user] Re: escape from i3lock
A wrapper script like this seems to do the trick. #!/bin/bash setxkbmap -option srvrkeys:none i3lock -c 003355 -n setxkbmap -option '' Artur Ian Zimmerman writes: On 2019-07-10 20:44, François-Xavier CARTON wrote: > On 7/10/19 7:03 PM, Ian Zimmerman wrote: > > Here is my next "low information" question, haha. > > > > I use i3lock which is like Xscreensaver but much much simpler; it plays > > no movies or games, just blanks the screen with a configured color or > > image. To unlock it you have to type your password. > > > > It bothers me that even when i3lock has locked the X session, I can > > still switch to other Linux virtual consoles with Alt-Control-F , > > without typing the password. It so happens that on one of the other > > virtual consoles there is often an interactive root shell :-P > > > > So, is it possible to prevent virtual console switching while the X > > screen is locked, but still allow it at other times? Looks like > > something the locker program would have to do, not the X server; but > > again I don't know much about this stuff. > > > > Not a direct answer to your question, but as a workaround you can use > tmux sessions, and simply detach them and logout when you lock your > computer. I could also just log out directly :-) It's not like I have some context in the shell that I want to keep. It is just there when I want to be root. > Also, if this is just a shell to start the X server, you can launch it > as "startx & bg; disown" and then logout. No, it's my way to run things as root, in general. I distrust su, sudo and friends. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
I guess you are using xorg. man xorg says that there is an option in serverflags section which disables this functionality. Option "DontVTSwitch" "boolean" So you could add a section into xorg.conf or xorg.conf.d/ Artur Ian Zimmerman writes: On 2019-07-10 20:44, François-Xavier CARTON wrote: > On 7/10/19 7:03 PM, Ian Zimmerman wrote: > > Here is my next "low information" question, haha. > > > > I use i3lock which is like Xscreensaver but much much simpler; it plays > > no movies or games, just blanks the screen with a configured color or > > image. To unlock it you have to type your password. > > > > It bothers me that even when i3lock has locked the X session, I can > > still switch to other Linux virtual consoles with Alt-Control-F , > > without typing the password. It so happens that on one of the other > > virtual consoles there is often an interactive root shell :-P > > > > So, is it possible to prevent virtual console switching while the X > > screen is locked, but still allow it at other times? Looks like > > something the locker program would have to do, not the X server; but > > again I don't know much about this stuff. > > > > Not a direct answer to your question, but as a workaround you can use > tmux sessions, and simply detach them and logout when you lock your > computer. I could also just log out directly :-) It's not like I have some context in the shell that I want to keep. It is just there when I want to be root. > Also, if this is just a shell to start the X server, you can launch it > as "startx & bg; disown" and then logout. No, it's my way to run things as root, in general. I distrust su, sudo and friends. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
On 2019-07-10 20:44, François-Xavier CARTON wrote: > On 7/10/19 7:03 PM, Ian Zimmerman wrote: > > Here is my next "low information" question, haha. > > > > I use i3lock which is like Xscreensaver but much much simpler; it plays > > no movies or games, just blanks the screen with a configured color or > > image. To unlock it you have to type your password. > > > > It bothers me that even when i3lock has locked the X session, I can > > still switch to other Linux virtual consoles with Alt-Control-F , > > without typing the password. It so happens that on one of the other > > virtual consoles there is often an interactive root shell :-P > > > > So, is it possible to prevent virtual console switching while the X > > screen is locked, but still allow it at other times? Looks like > > something the locker program would have to do, not the X server; but > > again I don't know much about this stuff. > > > > Not a direct answer to your question, but as a workaround you can use > tmux sessions, and simply detach them and logout when you lock your > computer. I could also just log out directly :-) It's not like I have some context in the shell that I want to keep. It is just there when I want to be root. > Also, if this is just a shell to start the X server, you can launch it > as "startx & bg; disown" and then logout. No, it's my way to run things as root, in general. I distrust su, sudo and friends. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
On 2019-07-10 15:23, Alec Ten Harmsel wrote: > On Wed, Jul 10, 2019 at 10:03:42AM -0700, Ian Zimmerman wrote: > > Here is my next "low information" question, haha. > > > > I use i3lock which is like Xscreensaver but much much simpler; it plays > > no movies or games, just blanks the screen with a configured color or > > image. To unlock it you have to type your password. > > It bothers me that even when i3lock has locked the X session, I can > > still switch to other Linux virtual consoles with Alt-Control-F , > > without typing the password. It so happens that on one of the other > > virtual consoles there is often an interactive root shell :-P > > > > So, is it possible to prevent virtual console switching while the X > > screen is locked, but still allow it at other times? Looks like > > something the locker program would have to do, not the X server; but > > again I don't know much about this stuff. > > Which init are you using, what display manager, and how are you > launching it? I'm using systemd and sddm, and when I run `i3lock', I > cannot switch to different virtual consoles. > > Not sure whether any of that stuff matters, but that was the first thing > I thought of. It does matter. Sysvinit, xdm via an initscript. Not so long ago, no DM at all, just startx/xinit. This is probably a function of consolekit or some of the other awful *kits. Not installing one of those. I'll find a workaround. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
