From patchwork Tue Aug 19 05:34:05 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dhiraj Kamble X-Patchwork-Id: 4740641 Return-Path: X-Original-To: patchwork-ceph-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 8A42C9F344 for ; Tue, 19 Aug 2014 05:34:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 929C920131 for ; Tue, 19 Aug 2014 05:34:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 735BA2010F for ; Tue, 19 Aug 2014 05:34:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752634AbaHSFeW (ORCPT ); Tue, 19 Aug 2014 01:34:22 -0400 Received: from mail-bn1blp0189.outbound.protection.outlook.com ([207.46.163.189]:41851 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752586AbaHSFeV convert rfc822-to-8bit (ORCPT ); Tue, 19 Aug 2014 01:34:21 -0400 Received: from BN1PR02CA0026.namprd02.prod.outlook.com (10.141.56.26) by BY2PR02MB042.namprd02.prod.outlook.com (10.242.44.21) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Tue, 19 Aug 2014 05:34:08 +0000 Received: from BN1AFFO11FD028.protection.gbl (2a01:111:f400:7c10::164) by BN1PR02CA0026.outlook.office365.com (2a01:111:e400:2a::26) with Microsoft SMTP Server (TLS) id 15.0.1010.18 via Frontend Transport; Tue, 19 Aug 2014 05:34:07 +0000 Received: from sacsmgep12.sandisk.com (74.221.232.164) by BN1AFFO11FD028.mail.protection.outlook.com (10.58.52.88) with Microsoft SMTP Server id 15.0.1010.11 via Frontend Transport; Tue, 19 Aug 2014 05:34:07 +0000 X-AuditID: ac1c210f-f79a76d0000025aa-d7-53f2e1cd3126 Received: from SACHUBIP01.sdcorp.global.sandisk.com ( [172.28.1.254]) by sacsmgep12.sandisk.com (Symantec Messaging Gateway) with SMTP id F3.1D.09642.DC1E2F35; Mon, 18 Aug 2014 22:34:05 -0700 (PDT) Received: from SACMBXIP01.sdcorp.global.sandisk.com ([169.254.1.44]) by SACHUBIP01.sdcorp.global.sandisk.com ([10.181.10.103]) with mapi id 14.03.0181.006; Mon, 18 Aug 2014 22:34:06 -0700 From: Dhiraj Kamble To: "ceph-devel@vger.kernel.org" Subject: Swift Upload/Post failing - 403 Forbidden Thread-Topic: Swift Upload/Post failing - 403 Forbidden Thread-Index: Ac+7by4Jc3rlUAmuR+GN6J8Ab0fs5g== Date: Tue, 19 Aug 2014 05:34:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.181.8.64] MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsWyRobxn+7Zh5+CDe6eULD4cHMSkwOjx+dN cgGMUVw2Kak5mWWpRfp2CVwZ398tYi9YLVlx8ko3YwPjdpEuRk4OCQETiY5dTawQtpjEhXvr 2UBsIYHjjBJdr+S7GLmA7P2MErf+7gYrYhPQlzjd+pwJxBYRsJXYOPsnI4gtLGAkMf3cChaI uLnEjFONULaexNotr8FqWARUJY4+PQLUy8HBKxAtsWy3D0iYEWjv91NrwEYyC4hL3Hoynwni HgGJJXvOM0PYohIvH/9jBWmVEJCXuH7aDqJcR2LB7k9sELa2xLKFr8HKeQUEJU7OfMIygVF4 FpKps5C0zELSMgtJywJGllWMYsWJycW56akFhkZ6xYl5KZnF2XrJ+bmbGMHhrci/g3HbFPND jAIcjEo8vAXvPwYLsSaWFVfmHmKU4GBWEuG9du9TsBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe VW6zgoUE0hNLUrNTUwtSi2CyTBycUg2MJWyiX99c7PxXnWiUeypSp2/PrrfCQIOfmX3lz3jz SHx/DevBM9HRh9pZfNJqJ4Q8ZJHW9uRYV3BL5ERosbz9oxTP4M1P3W/bHV5twNEsKZShH2J1 t32Ljp7v5rwDEeukddXLOj2FMz9uDZO32aa9PiPX3s/eN+fPAlPRvABjvhuMix8kK7EUZyQa ajEXFScCAJfjsuRrAgAA X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:74.221.232.164; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009006)(6009001)(438002)(374574003)(199003)(189002)(86362001)(16796002)(110136001)(46102001)(33656002)(95666004)(85806002)(81342001)(229853001)(2656002)(74502001)(31966008)(81542001)(74662001)(92726001)(15975445006)(84676001)(83072002)(77982001)(47776003)(79102001)(92566001)(23726002)(46406003)(97736001)(97756001)(21056001)(44976005)(106466001)(15202345003)(55846006)(4396001)(76482001)(80022001)(68736004)(87936001)(64706001)(85306004)(85852003)(81156004)(107046002)(2351001)(20776003)(107886001)(54356999)(77096002)(99396002)(19580395003)(83322001)(50466002)(69596002)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR02MB042; H:sacsmgep12.sandisk.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0308EE423E Received-SPF: Pass (protection.outlook.com: domain of sandisk.com designates 74.221.232.164 as permitted sender) receiver=protection.outlook.com; client-ip=74.221.232.164; helo=sacsmgep12.sandisk.com; Authentication-Results: spf=pass (sender IP is 74.221.232.164) smtp.mailfrom=Dhiraj.Kamble@sandisk.com; X-OriginatorOrg: sandisk.com Sender: ceph-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, Recent changes to rgw(post ceph 0.78), caused an issue while creating a key for SWIFT subuser. An empty string is entered into the .users.swift pool instead of the expected id(user:subuser). Although "radosgw-admin user info" shows the required information; when doing a swift put; rgw errors out with 403; as the required user does not match with the users in .users.swift pool. Doing a "rados ls -p .users.swift" will show nothing - it's an empty string and goes unnoticed. Infact, one can do Swift Uploads/Puts using an empty string as the swift user; but will give an 403 if you specify the "user:subuser" instead. Several users on the ceph-users mailing list have also reported similar issues. Opened a tracker: http://tracker.ceph.com/issues/9155 Here's the pull request: https://github.com/ceph/ceph/pull/2281 Please find below the diff. The fix also takes care of an user specifying an access key as an input while creating a SWIFT key - which should not be allowed(we could do some checking & clean up there). The user specifying "--gen-access-key" option is just fine; cause it just sets the "gen_access" variable to true - which is used to create the id during SWIFT key creation. An access key is required only for S3; providing one while creating a SWIFT key will cause the swift id to be set as the "access key" instead of the expected "user:subuser" id. This will cause the access key to be entered into the .users.swift pool instead of the subuser "user:subuser". So we again hit 403 error when we try using expected "user:subuser" as the swift user. No doing a "rados ls -p .users.swift" will show the expected users and not an empty string or the access key(if specified). Regards, Dhiraj diff --git a/src/rgw/rgw_user.cc b/src/rgw/rgw_user.cc index f21670a..a8d06b1 100644 --- a/src/rgw/rgw_user.cc +++ b/src/rgw/rgw_user.cc @@ -1040,6 +1040,15 @@ int RGWAccessKeyPool::add(RGWUserAdminOpState& op_state, std::string *err_msg, b int ret; std::string subprocess_msg; + if (op_state.get_key_type() == KEY_TYPE_SWIFT && !op_state.will_gen_access()) { + if (op_state.get_access_key().empty()) { + op_state.set_gen_access(); + } else { + set_err_msg(err_msg, "access key was specified during SWIFT key creation"); + return -EINVAL; + } + } + ret = check_op(op_state, &subprocess_msg); if (ret < 0) { set_err_msg(err_msg, "unable to parse request, " + subprocess_msg);