can the sha1 be fetched directly though ?  if people can `ls-remote` the ref, they can see the sha1 to explicitly fetch.

The Read permission filters the ls-remote view.

The git protocol does not allow fetching by SHA1; you have to start from a ref. I believe this was done for security reasons in case you leak a commit ID out of band.

Needs verification, but I think gitiles also enforces both of these restrictions.

seems to work for me:
chromite$ git log -1 f993fbeefc2796f37f871933f55fbb93f3091391
fatal: bad object f993fbeefc2796f37f871933f55fbb93f3091391

chromite$ git fetch cros f993fbeefc2796f37f871933f55fbb93f3091391
remote: Counting objects: 447, done
remote: Finding sources: 100% (281/281)
remote: Total 281 (delta 192), reused 263 (delta 192)
Receiving objects: 100% (281/281), 78.94 KiB | 3.59 MiB/s, done.
Resolving deltas: 100% (192/192), done.
From https://chromium.googlesource.com/chromiumos/chromite
 * branch                      f993fbeefc2796f37f871933f55fbb93f3091391 -> FETCH_HEAD

chromite$ git log -1 f993fbeefc2796f37f871933f55fbb93f3091391
commit f993fbeefc2796f37f871933f55fbb93f3091391
Author: Simon Glass <sjg@chromium.org>
Date:   Wed Feb 15 10:48:55 2012 -0800

    wip
    
    Change-Id: Iabe09f3ee78491dc5b934e31989a0a5762ee2c7f

Interesting. Must be a difference in the gerrit git implementation. I suspect that you still need access to some branch that can reach the commit; I'll try to verify that on Monday.

if the server side was able to enforce ACLs that only allowed fetching sha1s based on refs you had access to, that'd be great

Sadly, it doesn't work.