extract-archive needs admin account

The bulk middleware basically takes the incoming tar file stream and makes separate subrequests for each file using the credentials from the first request. Each of those subrequests will be handled separately by the auth middleware. As long as the bulk middleware is to the left of the auth and other restriction type middleware in the proxy pipeline those subrequests should be equivalent to the client making each PUT separately for each file within the tar. The container ACLs will likewise be honored.

Okay, I'm definitely not seeing that behavior.

Here's what I'm seeing:

1. If I authenticate as a service admin user, all bulk operations succeed (and as an admin, I appear to be immune to container quota values. Not sure if this is correct, but it makes sense).

2. If I authenticate as a user that is part of a ReadWrite role that is assigned to the X-Container-Write ACL, I get 403 Forbidden errors when attempting to auto-extract the archive either into an existing container or by trying to create the container as part of the extraction (I would expect this scenario to fail during the container creation, so that is okay).

What I've verified is that the keystoneauth authorize function in a normal upload is hit twice. Once by the proxy.server (where there are no role definitions returned by the getattr(req, 'acl', None) call), and then again by the proxy.controller.obj class (where the getattr call does return the proper ReadWrite role value and the file upload succeeds.

When doing the auto-extract though, for each file that is attempted to be extracted, only the first call by the proxy.server class seems to hit the keystone.authorize() function. Since there is no role information associated with this call, the denied_response is returned.

I'm at a loss as to this difference in behavior other than the fact that bulk.py is making subrequests using Request.blank(). Is something getting lost in the mix?

Thanks,

Steve

can you show me your proxy-server.conf ?

The proxy-server.conf is provided. It has been sanitized a bit, but should represent what's in place.

[DEFAULT]
bind_port = 8080
bind_ip = xxx.xxx.xxx.xxx
user = swift
swift_dir = /etc/swift
workers = 16

[pipeline:main]
pipeline = catch_errors proxy_logging cache bulk auth swiftauth proxy_logging proxy-server

[app:proxy-server]
use = egg:swift#proxy
allow_account_management = true
account_autocreate = false
set log_name = proxy-server
client_timeout = 90

[filter:proxy_logging]
use = egg:swift#proxy_logging

[filter:catch_errors]
use = egg: swift#catch_errors
set log_name = catch_errors

[filter:cache]
use = egg:swift#memcache
set log_name = proxy-swift-memcache

[filter:auth]
use = egg:mymodule#basicauth
#this contains some configuration for custom auth module. Omitted here

[filter:swiftauth]
use = egg:mymodule#swiftauth
operator_roles = StorageServiceAdministrator
is_admin = false
reseller_admin_role = <reseller_role>
#this is simply a reuse of the keystone auth with some additional code to interact with
#auth module above

[filter:account-quotas]
use = egg:swift#account_quotas

[filter:container-quotas]
use = egg:swift#container_quotas

[filter:bulk]
use = egg:swift#bulk
set log_name = swift-bulk

hmm... well its probably a bug somewhere in there then. It should work as I described. unfortunately i don't have time to check it out today- can you submit a bug report and I'll look at it next week?

David,

  Bug 1203182 has been filed for this issue. Thanks!

This question was expired because it remained in the 'Open' state without activity for the last 15 days.