What You See Is Not What You Get: Weird Behaviors in S3 Bucket Policies

I wrote this up since, over the past year, I've encountered more and more weird behavior with s3 bucket policies.

I haven't seen all of this behavior documented in a single place, so here it is.

Some of it has security implications (such as being able to brute force usernames) that is worth knowing about.

A TL;DR of the security stuff:

* Brute-forcing valid principal names is possible, since you can't create a bucket policy with an invalid principal.

* User compromise will break cross-account access, since if AWS becomes aware of a compromise, they will want you to delete the user and recreate it.

* Explicit denies will stop working if the principal is deleted and recreated, since they operate internally on the Principal ID and not the ARN

* Canonical IDs offer no extra security compared to account ARNs, since it's trivial to convert them back and get an account number.