OpenAFS Master Repository branch, master, updated. BP-openafs-stable-1_8_x-347-g635594d

Gerrit Code Review gerrit@openafs.org
Sat, 23 Mar 2019 18:45:02 -0400


The following commit has been merged in the master branch:
commit 635594d6cceba6de4e09be5a9e9b908f7d16697d
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Wed Mar 13 18:30:43 2019 -0500

    rx: Do not ignore RXS_* op errors
    
    Several places in rx call an RXS_* security layer operation, but
    ignore the error code. Though errors for these operations are rare or
    impossible currently, if they ever do return an error there could be
    noticeable consequences, like a connection getting an uninitialized
    challenge nonce, or sending a challenge packet with uninitialized
    payload.
    
    Change these call sites to record and handle the error. Errors from
    the security class normally mean aborting the entire conn, but for
    many operations we need to behave differently:
    
    - For RXS_DestroyConnection, errors don't make sense, since we're just
      freeing an object. Change the op to return void, and update our
      implementations of DestroyConnection to match.
    
    - For RXS_GetStats, just clear the relevant stats structure on error
      instead. This change also results in us clearing the stats structure
      when there is no security class associated with the connection;
      previously we just reused the same struct data as the previous conn.
    
    - For RXS_CreateChallenge, aborting the entire conn is difficult,
      because some code paths have callers that potentially lock multiple
      calls on the same conn (rxi_UpdatePeerReach -> TryAttach ->
      rxi_ChallengeOn -> RXS_CreateChallenge), and aborting our conn
      requires locking every call on the conn. So instead we just
      propagate an error up to our callers, and we abort just the call we
      have.
    
    - For RXS_GetChallenge, we cannot abort the conn when
      rxi_ChallengeEvent is called directly, because the caller will have
      the call locked. But when rxi_ChallengeEvent is called as an event
      (when we retry sending the challenge), we can.
    
    - For RXS_SetConfiguration, propagate the error up to our caller.
      Update all rx_SetSecurityConfiguration callers to record and handle
      the error; all of these are during initialization of daemons, so
      have them log an error and exit.
    
    Change-Id: I138b3e06da00470c7d70c458879cc741d296d225
    Reviewed-on: https://gerrit.openafs.org/13522
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

 src/bozo/bosserver.c         |    8 +++-
 src/ptserver/ptserver.c      |    8 +++-
 src/rx/rx.c                  |   97 +++++++++++++++++++++++++++++++++---------
 src/rx/rx.h                  |   10 +++-
 src/rx/rx_packet.c           |   13 +++++-
 src/rxgk/rxgk_client.c       |    7 +--
 src/rxgk/rxgk_server.c       |    7 +--
 src/rxkad/rxkad_common.c     |   10 +---
 src/rxkad/rxkad_prototypes.h |    4 +-
 src/viced/viced.c            |    8 +++-
 src/vlserver/vlserver.c      |    9 +++-
 src/volser/volmain.c         |   10 +++-
 12 files changed, 138 insertions(+), 53 deletions(-)

-- 
OpenAFS Master Repository