Upload on container with write ACL reports errors

Bug #1204558 reported by Fabien Boucher
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
python-swiftclient
Confirmed
Medium
Peter Tran

Bug Description

On swift configured on devstack, I'm unable to upload object in a container where Write ACL has been set by using the swift client. Performing same operation with curl client works as expected.

Command outputs :
The container where wite ACL has been set. demo user owns the Admin role.
 $ swift --os-tenant-name=demo --os-username=demo --os-password=wxcvbn --os-auth-url=http://localhost:5000/v2.0 s
tat container
  Account: AUTH_cbd3ac87d06b4f73b096ae2d4bcbb477
Container: container
  Objects: 3
    Bytes: 10724
 Read ACL:
Write ACL: demo:demouser2
  Sync To:
 Sync Key:
Accept-Ranges: bytes
X-Timestamp: 1374660280.52319
X-Trans-Id: tx12fce7c35acb40b2bcf9f09742ea762d
Content-Type: text/plain; charset=utf-8

The user demouser2 has no roles but it is allowed to PUT object in container 'container'. But two errors are return. This command should work according to the write ACL.
$ swift --os-tenant-name=demo --os-username=demouser2 --os-password=demouser2 --os-auth-url=http://localhost:500
0/v2.0 upload container exercise.sh
Error trying to create container 'container': 403 Forbidden: <html><h1>Forbidden</h1><p>Access was denied to this resourc
Object HEAD failed: http://192.168.56.102:8080/v1/AUTH_cbd3ac87d06b4f73b096ae2d4bcbb477/container/exercise.sh 403 Forbidden

If I configure the write ACL plus the read ACL the object is uploaded but an error is still returned :
$ swift --os-tenant-name=demo --os-username=demo --os-password=wxcvbn --os-auth-url=http://localhost:5000/v2.0 p
ost container -r 'demo:demouser2'
$ swift --os-tenant-name=demo --os-username=demouser2 --os-password=demouser2 --os-auth-url=http://localhost:500
0/v2.0 upload container exercise.sh
Error trying to create container 'container': 403 Forbidden: <html><h1>Forbidden</h1><p>Access was denied to this resourc
exercise.sh
$ swift --os-tenant-name=demo --os-username=demo --os-password=wxcvbn --os-auth-url=http://localhost:5000/v2.0 l
ist container
exercise.sh

If I use curl to perform the same operation:
$ T=$(keystone --os-tenant-name=demo --os-username=demouser2 --os-password=demouser2 --os-auth-url=http://localh
ost:5000/v2.0 token-get | awk '/ id / {print $4}')
$ swift --os-tenant-name=demo --os-username=demo --os-password=wxcvbn --os-auth-url=http://localhost:5000/v2.0 s
tat container
  Account: AUTH_cbd3ac87d06b4f73b096ae2d4bcbb477
Container: container
  Objects: 3
    Bytes: 10724
 Read ACL:
Write ACL: demo:demouser2
  Sync To:
 Sync Key:
Accept-Ranges: bytes
X-Timestamp: 1374660280.52319
X-Trans-Id: tx12fce7c35acb40b2bcf9f09742ea762d
Content-Type: text/plain; charset=utf-8
$ curl -XGET -H "X-Auth-Token: $T" http://localhost:8080/v1/AUTH_cbd3ac87d06b4f73b096ae2d4bcbb477/container/open
rc
<html><h1>Forbidden</h1><p>Access was denied to this resource.</p></html>fabien@devstack-local:~/devstack$
$ curl -i -XPUT -H "X-Auth-Token: $T" --data-binary "bouh" http://localhost:8080/v1/AUTH_cbd3ac87d06b4f73b096ae2
d4bcbb477/container/openrc
HTTP/1.1 201 Created
Last-Modified: Wed, 24 Jul 2013 15:06:22 GMT
Content-Length: 0
Etag: c9c5384adec41a13eea91ed4d20d809e
Content-Type: text/html; charset=UTF-8
X-Trans-Id: tx122f5662075f4c8d8f316021468982bf
Date: Wed, 24 Jul 2013 15:06:22 GMT

Changed in python-swiftclient:
assignee: nobody → Fabien Boucher (fabien-boucher)
status: New → Triaged
Changed in python-swiftclient:
status: Triaged → Confirmed
importance: Undecided → Medium
assignee: Fabien Boucher (fabien-boucher) → nobody
Peter Tran (pete-tran02)
Changed in python-swiftclient:
assignee: nobody → Peter Tran (pete-tran02)
Revision history for this message
Pete Zaitcev (zaitcev) wrote :

Peter, you might want to have a look at Thiago's patch
 https://review.openstack.org/60400

Revision history for this message
Janie Richling (jrichli) wrote :

Thiago or Peter: are you still working this? If not, I might revive Thiago's patch or start a new one. I can still reproduce the error.

Revision history for this message
Janie Richling (jrichli) wrote :

After looking into this a bit, I see that https://github.com/openstack/python-swiftclient/commit/9593d4b58a5e9f240e26d7873d3cc251c7d51f71 may have been the most that can be done for this. This has changed to only a warning, and the error code returned changed from a 1 to a 0. I am still looking to see if something more specific to this issue could be done.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to python-swiftclient (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/python-swiftclient/+/824281

Revision history for this message
Tim Burke (1-tim-z) wrote :

The first error has turned into a warning, as Janie pointed out. Even before https://github.com/openstack/python-swiftclient/commit/9593d4b, though, an upload via a write-only ACL would be possible; it'd just require --leave-segments (since you cannot read the object to determine whether it's some flavor of large object) and it would exit non-zero.

We might further improve things by:

- adding an option to skip the container PUT, so we don't even display the warning about being unable to create the container and
- documenting how write-only access requires the use of --leave-segments (since you cannot read the object to determine whether it's some flavor of large object)

I proposed https://review.opendev.org/c/openstack/python-swiftclient/+/824281 to add a --skip-container-put option at least.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to python-swiftclient (master)

Reviewed: https://review.opendev.org/c/openstack/python-swiftclient/+/824281
Committed: https://opendev.org/openstack/python-swiftclient/commit/f1858d89e0e1889664ced654755c508f47a0c1f3
Submitter: "Zuul (22348)"
Branch: master

commit f1858d89e0e1889664ced654755c508f47a0c1f3
Author: Tim Burke <email address hidden>
Date: Tue Jan 11 16:05:39 2022 -0800

    Add option to skip container PUT during upload

    Currently, a user with read/write access to a container (but without
    access to creat new containers) recieves a warning every time they
    upload. Now, allow them to avoid the extra request and warning by
    specifying --skip-container-put on the command line.

    This is also useful when testing: developers can HEAD a container to
    ensure it's in memcache, shut down all container servers, then upload
    and creaate a bunch of async pendings. Previously, the 503 on container
    PUT would prevent the object upload from even being attempted.

    Closes-Bug: 1317956
    Related-Bug: 1204558
    Change-Id: I3d9129a0b6b65c6c6187ae6af003b221afceef47
    Related-Change: If1f8a02ee7459ea2158ffa6e958f67d299ec529e

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.