Re: [i3] Detecting screen locked

2015-05-01 Thread Jeff Abrahamson
Good idea, thanks, I'll bind my lock key to that.  I think I learned of
xautolock after learning that I could lock the screen by binding i3lock to
a key.

Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255<-- only if I'm in the UK

http://jeff.purple.com/
http://blog.purple.com/jeff/

On 1 May 2015 at 17:44, Serge van Ginderachter 
wrote:

>
> On 1 May 2015 at 17:40, Jeff Abrahamson  wrote:
>
>> I lock the screen from the keyboard.  That key is bound to i3lock --dpms
>> --inactivity-timeout 10 --color=220022 .
>>
>
>
> ​If you use xautolock, better trigger a lock through it then, I use the
> Pause button to lock it like this:
>
>bindsym Pause exec "xautolock -locknow"​
>
>
>


Re: [i3] Detecting screen locked

2015-05-01 Thread Serge van Ginderachter
On 1 May 2015 at 17:40, Jeff Abrahamson  wrote:

> I lock the screen from the keyboard.  That key is bound to i3lock --dpms
> --inactivity-timeout 10 --color=220022 .
>


​If you use xautolock, better trigger a lock through it then, I use the
Pause button to lock it like this:

   bindsym Pause exec "xautolock -locknow"​


Re: [i3] Detecting screen locked

2015-05-01 Thread Jeff Abrahamson
A bit more info.  It appears that the sequence of events may be the
following:

I lock the screen from the keyboard.  That key is bound to i3lock --dpms
--inactivity-timeout 10 --color=220022 .

A bit later, xautolock decides to lock the screen as well.  That command,
by chance, is not quite the same, which is how I identified the two
locks.  i3lock
--dpms --color=220022 --inactivity-timeout 10 --nofork

There is no good reason they are different, but they do both run
sometimes.  For some reason, the xautolock-launched version sometimes
neither asks for my password nor exits.  This doesn't happen every time,
most of the time, it all works correctly.


Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255<-- only if I'm in the UK

http://jeff.purple.com/
http://blog.purple.com/jeff/

On 17 April 2015 at 12:50, Michael Stapelberg  wrote:

> On Fri, Apr 17, 2015 at 3:00 AM, Jeff Abrahamson  wrote:
> > Thanks.  I understand (and a bit better, now) why strace/ptrace may have
> > problems with a program that calls setuid.  On the other hand, i3lock
> > doesn't have the setuid bit set, and the strace logs do not show an
> attempt
> > to call strace.
> >
> > [S-18]jeff@siegfried:~ $ stat /usr/bin/i3lock
> >   File: ‘/usr/bin/i3lock’
> >   Size: 31912   Blocks: 64 IO Block: 4096   regular file
> > Device: fc01h/64513dInode: 1575208 Links: 1
> > Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
> > Access: 2015-04-16 20:02:56.634223226 +0200
> > Modify: 2014-07-19 01:13:09.0 +0200
> > Change: 2015-03-04 15:18:43.959784604 +0100
> >  Birth: -
> > [S-18]jeff@siegfried:~ $ grep setuid /tmp/i3lock-log-1429256*
> > 1,[S-18] jeff@siegfried:~ $
> >
> > This said, if something PAM did when I logged in affects the behavior of
> > stracing i3lock, I do not think I will try to figure out what PAM has
> done.
> > ;-)  But I still find it odd that i3lock would interpret keystrokes
> > differently under strace or not based on what I know so far.
>
> It doesn’t. I’m saying the PAM stack (outside of i3’s code) likely
> requires setuid permission for some modules (most likely pam_unix).
>
> >
> > Well, I will debug what I can.  Maybe I will compile an i3lock with
> > scaffolding over the weekend to see what I can learn.
> >
> > Thanks again.
> >
> > Jeff Abrahamson
> > +33 6 24 40 01 57
> > +44 7920 594 255<-- only if I'm in the UK
> >
> > http://jeff.purple.com/
> > http://blog.purple.com/jeff/
> >
> > On 17 April 2015 at 11:47, Michael Stapelberg  wrote:
> >>
> >> See http://superuser.com/a/248127 for why setuid is ignored when
> >> running under strace.
> >>
> >> Given that you run i3lock on linux, it might be PAM which uses setuid
> >> in some of its modules.
> >>
> >> On Fri, Apr 17, 2015 at 1:20 AM, Jeff Abrahamson 
> wrote:
> >> > Interesting.  How does setuid have this effect on i3lock but only
> under
> >> > strace?
> >> >
> >> > Any idea where the setuid is coming from or how to find out?  The
> system
> >> > is
> >> > pretty vanilla ubuntu 14.10 (they have a good installer) aside from
> >> > running
> >> > i3 instead of gnome.
> >> >
> >> > The exec path that's visible once I'm logged in is lightdm -> lightdm
> >> > --sesion-child -> i3.  I see that i3 parents what is executed due to
> >> > .xsessionrc.
> >> >
> >> > I'll try to gather traces with -p, but this will depend on me thinking
> >> > to
> >> > trace i3lock from a vt before unlocking the screen.  My apologies in
> >> > advance
> >> > if I take a long time to catch the occasional errant process that way.
> >> >
> >> > And thanks for your ever prompt assistance and insights.
> >> >
> >> > Jeff Abrahamson
> >> > +33 6 24 40 01 57
> >> > +44 7920 594 255<-- only if I'm in the UK
> >> >
> >> > http://jeff.purple.com/
> >> > http://blog.purple.com/jeff/
> >> >
> >> > On 17 April 2015 at 10:09, Michael Stapelberg 
> wrote:
> >> >>
> >> >> Ugh, then you’re running it in a setuid setup. You’ll need to start
> >> >> i3lock
> >> >> and then attach strace afterwards using -p.
> >> >>
> >> >> On Fri, Apr 17, 2015 at 9:56 AM, Jeff Abrahamson 
> >> >> wrote:
> >> >>>
> >> >>> I invoke i3lock at the commandline thus:
> >> >>>
> >> >>> [S-18]jeff@siegfried:gtd $ strace -o/tmp/i3lock-log-$(date +%s) -f
> -s
> >> >>> 2048 -tt  i3lock --dpms --inactivity-timeout 10 --color=220022
> >> >>> [S-18]jeff@siegfried:gtd $
> >> >>>
> >> >>> and the result is that i3lock does not recognize my password.  It
> does
> >> >>> echo my typing, it just always says fail.  I switch to a vt, login,
> >> >>> and kill
> >> >>> it.
> >> >>>
> >> >>> Jeff Abrahamson
> >> >>> +33 6 24 40 01 57
> >> >>> +44 7920 594 255<-- only if I'm in the UK
> >> >>>
> >> >>> http://jeff.purple.com/
> >> >>> http://blog.purple.com/jeff/
> >> >>>
> >> >>> On 17 April 2015 at 09:39, Michael Stapelberg 
> >> >>> wrote:
> >> 
> >>  Yes, but also use -f (to follow child processes) and -s 2048 (to
> >>  increase the size of strings) and -tt (to get