テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(akka-s3 report) anonymous userをサポートする

S3では,

  • Authorizationヘッダなどに署名を乗せてきた場合 -> Authenticated User
  • それがない場合 -> Anonymouse User

というUserの種別がある. S3の仕様はAuthenticated Userを基本にして書いてあり, Anonymousについては抜けが多い.

Authenticated Userだけをサポートすることが確実であり, 楽であり, Anonymousの場合は特殊なユーザにfallbackするという実装をしようかとも思ったが, やはりAnonymousをしっかりと実装することにした.

Anonymousでもっとも危ない仕様は, 「public-writeなバケットに対して, Anonymousがupload可能である」という仕様である. これは大変危険な仕様である. public-read-writeというcanned aclの説明は,

Owner gets FULL_CONTROL. The AllUsers group gets READ and WRITE access. Granting this on a bucket is generally not recommended.

となっており, ではどうしてこんなものが存在するのか. publicより制約のきついAuthenticated User一般へのcanned aclでは, read権限を与えるものまでしかないので, 仕様に一貫性がないとも言える. 一方で, public-readには意味がある. これは, Presigned Requestをばらまかずともオブジェクトへの参照を許すことには, 利便性の点で意味がある. (と, 私は思わないが少なくとも世間はそう思っている)

以上より, 私の頭の中にはいくつかの選択肢があった.

  1. (冒頭に述べたように)Authenticatedだけを実装して, Anonymousは特殊なユーザにfallbackする
  2. public-readまでを実装する. publicなユーザは, ストレージに対して副作用を与えられないようにする.

一見すると1は筋が良さそうだが, 例えば, その特殊なユーザとAuthenticatedユーザはどうやって区別するのか?などを考慮していくと, 結局Anonymousユーザを実装していることと大差なくなる可能性が高い.

従って, Authenticated, Anonymousはしっかりと区別して実装する方針でいき(実装上は, Option[String]で表現してある. NoneであればAnonymous. この2つの差については型チェックの保護を欲した), 将来的にpublic-read-writeをサポートしていくというロードマップを描くことにした. (public-read-writeには仕様矛盾がある可能性があるため攻めれない)

Anonymousユーザに関して仕様にないものとしては, 仮にそれがオブジェクトを作り, ownerとなった場合, GET Bucketの各オブジェクトのowner属性はどうなるのか?がある. 私の調査では, Ownerを"anonymous"として, DisplayNameを空とするというのがもっとも正解に近いと結論づけた. (ただCephがそうなっているからという蛆虫みたいな理由である: [ceph-users] Using S3 REST API)

どのユーザ種別に対してもread/writeを完全に実装することの利点は, PutBucketACLなど横道から設定をいかにいじられようとも対応出来ることである. なので, 将来的には対応していくのが良いとは思っている.