All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Elder <elder@inktank.com>
To: Sage Weil <sage@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: [PATCH 3/6] libceph: add update_authorizer auth method
Date: Mon, 25 Mar 2013 09:15:25 -0500	[thread overview]
Message-ID: <51505BFD.6030005@inktank.com> (raw)
In-Reply-To: <1363734486-26879-3-git-send-email-sage@inktank.com>

On 03/19/2013 06:08 PM, Sage Weil wrote:
> Currently the messenger calls out to a get_authorizer con op, which will
> create a new authorizer if it doesn't yet have one.  In the meantime, when
> we rotate our service keys, the authorizer doesn't get updated.  Eventually
> it will be rejected by the server on a new connection attempt and get
> invalidated, and we will then rebuild a new authorizer, but this is not
> ideal.
> 
> Instead, if we do have an authorizer, call a new update_authorizer op that
> will verify that the current authorizer is using the latest secret.  If it
> is not, we will build a new one that does.  This avoids the transient
> failure.
> 
> This fixes one of the sorry sequence of events for bug
> 
> 	http://tracker.ceph.com/issues/4282
> 
> Signed-off-by: Sage Weil <sage@inktank.com>

A few things for you to consider below, but this looks
OK to me.

Reviewed-by: Alex Elder <elder@inktank.com>

> ---
>  fs/ceph/mds_client.c      |    7 ++++++-
>  include/linux/ceph/auth.h |    3 +++
>  net/ceph/auth_x.c         |   23 +++++++++++++++++++++++
>  net/ceph/auth_x.h         |    1 +
>  net/ceph/osd_client.c     |    5 +++++
>  5 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> index 06ea2ca..75cca49 100644
> --- a/fs/ceph/mds_client.c
> +++ b/fs/ceph/mds_client.c
> @@ -3445,7 +3445,12 @@ static struct ceph_auth_handshake *get_authorizer(struct ceph_connection *con,
>  	}
>  	if (!auth->authorizer && ac->ops && ac->ops->create_authorizer) {
>  		int ret = ac->ops->create_authorizer(ac, CEPH_ENTITY_TYPE_MDS,
> -							auth);
> +						     auth);
> +		if (ret)
> +			return ERR_PTR(ret);
> +	} else if (ac->ops && ac->ops_update_authorizer) {
> +		int ret = ac->ops->update_authorizer(ac, CEPH_ENTITY_TYPE_MDS,
> +						     auth);
>  		if (ret)
>  			return ERR_PTR(ret);
>  	}

It appears that this means a user of this interface could provide
only an update method and not a create method.  Maybe that's what
you intend.  It seems like maybe we should update if we can,
otherwise fall back to creating a new one.

I would argue that the logic of this might be better stated:

    if (!ac->ops)
        goto out;
    ret = 0;
    if (auth->authorizer && ac->ops->update_authorizer)
        ret = ac->ops->update_authorizer(...);
    else if (ac->ops->create_authorizer)
        ret = ac->ops->create_authorizer(...);
    if (ret)
        return ERR_PTR(ret);
out:
    *proto = ac->protocol;

(And use the same pattern for the osd client, below.)

> diff --git a/include/linux/ceph/auth.h b/include/linux/ceph/auth.h
> index d4080f3..73e973e 100644
> --- a/include/linux/ceph/auth.h
> +++ b/include/linux/ceph/auth.h
> @@ -52,6 +52,9 @@ struct ceph_auth_client_ops {
>  	 */
>  	int (*create_authorizer)(struct ceph_auth_client *ac, int peer_type,
>  				 struct ceph_auth_handshake *auth);
> +	/* ensure that an existing authorizer is up to date */
> +	int (*update_authorizer)(struct ceph_auth_client *ac, int peer_type,
> +				 struct ceph_auth_handshake *auth);
>  	int (*verify_authorizer_reply)(struct ceph_auth_client *ac,
>  				       struct ceph_authorizer *a, size_t len);
>  	void (*destroy_authorizer)(struct ceph_auth_client *ac,
> diff --git a/net/ceph/auth_x.c b/net/ceph/auth_x.c
> index bd8758d..2d59815 100644
> --- a/net/ceph/auth_x.c
> +++ b/net/ceph/auth_x.c
> @@ -298,6 +298,7 @@ static int ceph_x_build_authorizer(struct ceph_auth_client *ac,
>  			return -ENOMEM;
>  	}
>  	au->service = th->service;
> +	au->secret_id = th->secret_id;

The secret id for the ticket handler will be initially 0.

>  
>  	msg_a = au->buf->vec.iov_base;
>  	msg_a->struct_v = 1;
> @@ -555,6 +556,27 @@ static int ceph_x_create_authorizer(
>  	return 0;
>  }
>  
> +static int ceph_x_update_authorizer(
> +	struct ceph_auth_client *ac, int peer_type,
> +	struct ceph_auth_handshake *auth)
> +{
> +	struct ceph_x_authorizer *au;
> +	struct ceph_x_ticket_handler *th;
> +	int ret;
> +
> +	th = get_ticket_handler(ac, peer_type);
> +	if (IS_ERR(th))
> +		return PTR_ERR(th);
> +
> +	au = (struct ceph_x_authorizer *)auth->authorizer;
> +	if (au->secret_id < th->secret_id) {

Under what circumstances should the ticket handler's
secret id get incremented?  (This patch never actually
changes it from its initial value of 0.)

...OK, now I've looked at the existing code, and I
see that the secret id is already maintained in the
ceph_x reply buffer, this patch just starts making
use of it.  Apparently the ticket id is monotonically
increasing and never 0.

> +		dout("ceph_x_update_authorizer service %u secret %llu < %llu\n",
> +		     au->service, au->secret_id, th->secret_id);
> +		return ceph_x_build_authorizer(ac, th, au);
> +	}
> +	return 0;
> +}
> +
>  static int ceph_x_verify_authorizer_reply(struct ceph_auth_client *ac,
>  					  struct ceph_authorizer *a, size_t len)
>  {
> @@ -641,6 +663,7 @@ static const struct ceph_auth_client_ops ceph_x_ops = {
>  	.build_request = ceph_x_build_request,
>  	.handle_reply = ceph_x_handle_reply,
>  	.create_authorizer = ceph_x_create_authorizer,
> +	.update_authorizer = ceph_x_update_authorizer,
>  	.verify_authorizer_reply = ceph_x_verify_authorizer_reply,
>  	.destroy_authorizer = ceph_x_destroy_authorizer,
>  	.invalidate_authorizer = ceph_x_invalidate_authorizer,
> diff --git a/net/ceph/auth_x.h b/net/ceph/auth_x.h
> index f459e93..c5a058d 100644
> --- a/net/ceph/auth_x.h
> +++ b/net/ceph/auth_x.h
> @@ -29,6 +29,7 @@ struct ceph_x_authorizer {
>  	struct ceph_buffer *buf;
>  	unsigned int service;
>  	u64 nonce;
> +	u64 secret_id;
>  	char reply_buf[128];  /* big enough for encrypted blob */
>  };
>  
> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
> index cb14db8..5ef24e3 100644
> --- a/net/ceph/osd_client.c
> +++ b/net/ceph/osd_client.c
> @@ -2220,6 +2220,11 @@ static struct ceph_auth_handshake *get_authorizer(struct ceph_connection *con,
>  							auth);
>  		if (ret)
>  			return ERR_PTR(ret);
> +	} else if (ac->ops && ac->ops->update_authorizer) {
> +		int ret = ac->ops->update_authorizer(ac, CEPH_ENTITY_TYPE_OSD,
> +						     auth);
> +		if (ret)
> +			return ERR_PTR(ret);
>  	}
>  	*proto = ac->protocol;
>  
> 


  reply	other threads:[~2013-03-25 14:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19 23:08 [PATCH 1/6] libceph: clear messenger auth_retry flag when we authenticate Sage Weil
2013-03-19 23:08 ` [PATCH 2/6] libceph: fix authorizer invalidation Sage Weil
2013-03-25 13:39   ` Alex Elder
2013-03-25 15:51     ` Sage Weil
2013-03-19 23:08 ` [PATCH 3/6] libceph: add update_authorizer auth method Sage Weil
2013-03-25 14:15   ` Alex Elder [this message]
2013-03-25 15:53     ` Sage Weil
2013-03-19 23:08 ` [PATCH 4/6] libceph: wrap auth ops in wrapper functions Sage Weil
2013-03-25 14:25   ` Alex Elder
2013-03-19 23:08 ` [PATCH 5/6] libceph: wrap auth methods in a mutex Sage Weil
2013-03-25 14:32   ` Alex Elder
2013-03-25 16:26     ` Sage Weil
2013-03-25 16:49       ` Alex Elder
2013-03-19 23:08 ` [PATCH 6/6] libceph: verify authorizer reply Sage Weil
2013-03-25 14:41   ` Alex Elder
2013-03-25 16:29     ` Sage Weil
2013-03-25 13:32 ` [PATCH 1/6] libceph: clear messenger auth_retry flag when we authenticate Alex Elder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51505BFD.6030005@inktank.com \
    --to=elder@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=sage@inktank.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.