Comment 4 for bug 1449212

what are the privileges required to set a container tempurl key? If you have to be a swift_owner to set or read a container tempurl key then you already have privileges that you could theoretically elevate to - and this maybe more of a documentation issue. IIRC, account level tempurl keys allow you to grant temporary access to a manifest object regardless of the location of it's segment - so I think there's a strong analogy - and even if you hand out a PUT tempurl, and let someone create a cross-container manifest they'd still need to generate a GET tempurl to read cross container.

If we expect that container tempurl *keys* to be handed out to people that have a more restricted access than that - well that's probably different - object versioning would be the next most likely attack vector.

OTOH, perhaps regardless of the privilege level of the *expected* recipient of the key if the user story is that the attack surface of a tempurl key is reduced by restricting it to the container vs the account we may have to pursue a solution to limit the "pre-authorization" of requests to paths under the pre-authorized container. Perhaps leave a authorization callback in the environment and have it return 401 if the container in the path isn't the container who matched originally matched the tempurl key?

It seems like we need to understand the user expectation first. It may be surprising if you can *make* a tempurl for a segmented object - but can't acctually *use* it because the segments were in a different container? If we give out a tempurl for a PUT to overwrite an object in a versioned container - do we expect using the tempurl to PUT new data to be able to backup the existing object before the overwrite?