[gentoo-user] escape from i3lock

[gentoo-user] escape from i3lock

[Ian Zimmerman]

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<n> ,
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.

-- 
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] escape from i3lock

[François-Xavier CARTON]

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<n> ,
> 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.

[gentoo-user] Re: escape from i3lock

[Ian Zimmerman]

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<n> ,
> > 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

[artur.tamm.85]

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<n> ,
> > > 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

[artur.tamm.85]

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<n> ,
> > > 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

[Ian Zimmerman]

On 2019-07-10 23:46, artur.tamm.85@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

[Ian Zimmerman]

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

[artur.tamm.85]

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.
>

Re: [gentoo-user] Re: escape from i3lock

[Laurence Perkins]

[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]

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 +0000, artur.tamm.85@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.
> > 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-user] Re: escape from i3lock

[David Haller]

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

[Laurence Perkins]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]


> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-user] Re: escape from i3lock

[Michele Alzetta]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

I've been using

vlock -a

for years ... it works.

Il giorno ven 12 lug 2019 alle ore 03:18 Laurence Perkins <
lperkins@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
>

[-- Attachment #2: Type: text/html, Size: 1705 bytes --]

Re: [gentoo-user] Re: escape from i3lock

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

> 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 <some option>
more or less secure than su?"

[-- Attachment #2: Type: text/html, Size: 756 bytes --]

[gentoo-user] Re: escape from i3lock

[Ian Zimmerman]

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 <some option>
> 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.

[gentoo-user] Re: escape from i3lock

[Nuno Silva]

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<n> ,
>> 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

[Ian Zimmerman]

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

[Michele Alzetta]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

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 <itz@very.loosely.org> 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.
>
>

[-- Attachment #2: Type: text/html, Size: 1483 bytes --]

Re: [gentoo-user] Re: escape from i3lock

[Laurence Perkins]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]



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.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[gentoo-user] Re: escape from i3lock

[Nuno Silva]

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] escape from i3lock

[Alec Ten Harmsel]

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.

Same here, it's simple and just works.

> 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<n> ,
> 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.

Alec

Re: [gentoo-user] escape from i3lock

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

On Wed, 10 Jul 2019 15:23:08 -0400, Alec Ten Harmsel wrote:

> > 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<n> ,
> > 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.

I use slock for this with the same problem. I just tried i3lock, with
systemd and sddm, and I can still switch to a virtual console.


-- 
Neil Bothwick

If it ain't broke, break it and charge for repair.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] escape from i3lock

[Alec Ten Harmsel]

On Wed, Jul 10, 2019 at 09:52:55PM +0100, Neil Bothwick wrote:
> On Wed, 10 Jul 2019 15:23:08 -0400, Alec Ten Harmsel wrote:
> 
> > 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.
> 
> I use slock for this with the same problem. I just tried i3lock, with
> systemd and sddm, and I can still switch to a virtual console.
> 

I just don't know what I'm doing - I can switch virtual consoles too. I
had no idea that I had to press Ctrl + Alt + F[1-9].

Based on a cursory look[1] I'd guess this would be something that
i3lock has to implement. Or just workaround by using tmux or screen
instead of virtual consoles as someone else suggested.

Alec

1. https://askubuntu.com/questions/357039/how-do-i-disable-virtual-consoles-tty1-6

[gentoo-user] Re: escape from i3lock

[Ian Zimmerman]

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<n> ,
> > 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.

Re: [gentoo-user] escape from i3lock

[Francesco Turco]

On Wed, Jul 10, 2019, at 19:04, 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<n> ,
> 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.

A command such as physlock can be used to lock virtual terminals:
- https://github.com/muennich/physlock
- https://packages.gentoo.org/packages/app-misc/physlock

-- 
https://fturco.gitlab.io/