tree a5a0e0c0b1e6970c1aef8a38e2b45978c00b8592
parent 42ef7c742ab128b25478833a52af25ba0be5bf15
author Jan Schär <jan@jschaer.ch> 1710777817 +0100
committer Jan Schär <jan@jschaer.ch> 1710782676 +0000

m/node: fix appending to read-only slices

`append` modifies its first argument if there is sufficient capacity 
instead of allocating a new slice. If the slice to be appended to is 
supposed to be read-only, this can lead to unexpected aliasing.

An example of what can go wrong, here with the consensus client:

    l := NewLocal(nil)
    sub1, _ := l.Sub("I")
    sub2, _ := sub1.Sub("am")
    sub3, _ := sub2.Sub("a")
    dog, _ := sub3.Sub("dog")
    _, _ = sub3.Sub("cat")
    fmt.Print(dog.(*local).path)

Result before this change: "I am a cat"
Result after this change: "I am a dog"

After creating a subnamespace of length 3, the capacity of the `path` is 
4, so any subnamespace will share the same slice. The fix is to always 
ensure a new slice is allocated.

Impact
------

For the consensus client, Sub is currently never called multiple times 
on the same namespace, so there is no impact there. In case of the dhcp 
client and rpc resolver, the slices that are appended to are slice 
literals in all cases, which don't have extra capacity.

But for the curator `etcdPrefix`, `p.parts` has capacity 1 larger than 
the length, due to the slicing in `newEtcdPrefix`. That means that 
concurrent calls to `Key` can overwrite each other's `path`. It looks 
like `Key` can in fact be called concurrently, which means there is 
potential for data corruption to occur before this change.

Change-Id: I28e7dc797365c2beea97023ed31a20eea599e678
Reviewed-on: https://review.monogon.dev/c/monogon/+/2873
Vouch-Run-CI: Lorenz Brun <lorenz@monogon.tech>
Tested-by: Jenkins CI
Reviewed-by: Serge Bazanski <serge@monogon.tech>