openssh bugs - Apr 2014 - [Bug 2228] New: ssh-agent passwords do not timeout properly

https://bugzilla.mindrot.org/show_bug.cgi?id=2228

            Bug ID: 2228
           Summary: ssh-agent passwords do not timeout properly
           Product: Portable OpenSSH
           Version: 6.4p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: ssh-agent
          Assignee: unassigned-bugs at mindrot.org
          Reporter: john.haxby at oracle.com

Created attachment 2425
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2425&action=edit
proposed patch

I habitually run "ssh-add -t10h" when I open up my laptop in the
morning and then suspend it at the end of the working day, usually a
little while before the lifetime of the identities expires.

Recently, however, this hasn't worked because the agent still has the
identities the following morning.

I believe that this is because monotime() uses CLOCK_MONOTONIC but in
recent kernels this has changed slightly.  From clock_gettime(2):

    CLOCK_MONOTONIC
           Clock that cannot be set and  represents  monotonic  time
           since some unspecified starting point.  This clock is not
           affected by discontinuous jumps in the system time (e.g.,
           if  the system administrator manually changes the clock),
           but is affected by the incremental adjustments  performed
           by adjtime(3) and NTP.

    CLOCK_BOOTTIME (since Linux 2.6.39; Linux-specific)
           Identical to CLOCK_MONOTONIC, except it also includes any
           time  that the system is suspended.  This allows applica?
           tions to get a suspend-aware monotonic clock without hav?
           ing  to  deal  with  the complications of CLOCK_REALTIME,
           which may have discontinuities if  the  time  is  changed
           using settimeofday(2).

The attached patch seems to fix this: if CLOCK_MONOTONIC is available
then additionally check for CLOCK_BOOTTIME.  CLOCK_BOOTTIME is Linux
specific and will never be defined unless CLOCK_MONOTONIC is also
defined.

So far as I can tell this has not been addressed in the current
version.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2228

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2425|0                           |1
        is obsolete|                            |
   Attachment #2427|                            |ok?(dtucker at zip.com.au)
              Flags|                            |
                 CC|                            |djm at mindrot.org,
                   |                            |dtucker at zip.com.au
           Assignee|unassigned-bugs at mindrot.org |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Created attachment 2427
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2427&action=edit
Try CLOCK_BOOTTIME with fallback

It's probably better to try CLOCK_BOOTTIME first and fall back to
CLOCK_MONOTONIC, in case the system headers happen to have the former
but the kernel lacks support.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2228

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2226

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2228

--- Comment #2 from John Haxby <john.haxby at oracle.com> ---
I agree, I had thought the same thing overnight.   There are possible
cases where CLOCK_BOOTIME is defined at compile time but it not
available at run time so the fallback is definitely needed.  (I
actually have the opposite case: CLOCK_BOOTIME is available at run time
but not defined at compile time, but that's my problem, not yours.)

Your patch has a logical problem though: it won't compile if
CLOCK_BOOTTIME is defined but CLOCK_MONOTONIC is.   In practice this
won't happen, but perhaps you either want to surround the
CLOCK_MONOTONIC call with a #ifdef or you want to remove the test for
defined(CLOCK_BOOTTIME) from the surrounding #if.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2228

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
similar patch applied - this will be in openssh-6.7

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2228

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
Close all bugs left open from 6.6 and 6.7 releases.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2228

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2427|ok?(dtucker at dtucker.net)    |
              Flags|                            |

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.