On Tue, 29 Sep 2015 17:04:38 +0200 Mattias Andrée <maand...@kth.se> wrote:
> On Tue, 29 Sep 2015 16:53:26 +0200
> lists <li...@nvsbl.org> wrote:
>
> > by itself this does not provide much more security
> > because you can Ctrl-z in the originating TTY and get a
> > shell prompt ( with bash at least ).
> >
> > --seth
> >
> > > On 28 Sep 2015, at 16:39, Mattias Andrée
> > > <maand...@kth.se> wrote:
> > >
> > > On Mon, 28 Sep 2015 16:32:00 +0200
> > > Hinnerk van Bruinehsen <h.v.bruineh...@fu-berlin.de>
> > > wrote:
> > >
> > >>> On Sun, Sep 27, 2015 at 09:42:11PM +0800, Pickfire
> > >>> wrote:
> > >>>> On Sun, Sep 27, 2015 at 02:15:02PM +0200, 7heo
> > >>>> wrote: Put
> > >>>>
> > >>>> if ! pgrep xinit >/dev/null; then
> > >>>> start-stop-daemon -S -b startx
> > >>>> clear
> > >>>> exit
> > >>>> fi
> > >>>>
> > >>>> At the end if your ~/.${SHELL}rc file.
> > >>>
> > >>> What do you mean by that? I mean to disable Xorg
> > >>> Termination when using `slock`.
> > >>
> > >> Any kind of wrapper still exposes the terminal in
> > >> case X crashes: e.g. alt+f{whatever terminal startx
> > >> was run in} and ctrl+c ...
> > >
> > > So you should probably have
> > >
> > > alias startx="startx || logout"
> > >
> > > or
> > >
> > > alias startx="startx ; logout"
> > >
> > > in your shell.
> >
>
> Perhaps a screen locker for X is the wrong approach.
> Why not make a screen locker that chvt:s to a new
> VT and takes raw keyboard input from the kernel.
> Now, if anything crashes, you are stuck until you
> login remotely and reset things.
>
> Of course, this will be problematic if you already
> use all VT:s. But why would anyone.
Amendment, if the screen locker crashes, you get stuck.
If X crashes, nothing happens until you authenticate
yourself; then you will be returned to the VT where
X resided.
pgpROTAD6uzAY.pgp
Description: OpenPGP digital signature
