System keys are accessible by default with Go bindings

Using FoundationDB
1

Looks like a dangerous bug.

github.com/apple/foundationdb/bindings/go v0.0.0-20210729182842-f6596a740b02

// Can access without tx.Options().SetAccessSystemKeys()
tx.Get(fdb.Key("\xFF\xFF/cluster_file_path")).MustGet()

Another, a tuple element (of subspaces) starting with \xFF may also conflict with a system key? So shouldn’t I accept a tuple element starting with \xFF?

2

\xff\xff/cluster_file_path is actually not a system key, but instead a special key. Being able to access it without setting the “access system keys” transaction option is intentional. Part of the design of the tuple layer is that serialized keys should never start with \xff. Do you have an example of a tuple that starts with \xff when serialized? If so please share.

3

I see. However, anyway it looks dangerous.

I’ll use subspaces to escape the leading \xFF. Thanks!

4

What I’m saying is there won’t ever be a leading \xff in the serialized key.

>>> fdb.tuple.pack((b'\xff',))
'\x01\xff\x00'
5

So subspace.Sub("\xFF...") is unsafe?

6

The python binding (and probably all the bindings) use the tuple layer to encode the key prefix they use. The python binding provides a backdoor you can use to set the raw prefix directly, and using a prefix starting with \xff would be unsafe.

>>> fdb.Subspace(('foo',))
Subspace(rawPrefix='\x01foo\x00')
7

I see, I don’t use the raw prefix option. Thanks.