> > I’m not sure I understand the threat model.  If Knot has a RCE
> > vulnerability, it can be exploited to run anything on behalf of the
> > ‘knot’ user.
> > 
> > At that point, all the state associated with Knot in /var/lib should be
> > considered tainted; new keys should be generated, and so on.
> > 
> > Why focus on the permissions on /var/lib/knot?
> 
> My understanding is that, in case of an RCE in knot, the attacker can
> replace /var/lib/knot/* with symlinks to arbitrary files in the FS. When
> the activation procedure is run afterwards, the files being linked to
> are chowned to the knot user, and the attacker can access them.

That's exactly what I had in mind!  Though I would like to stress that
‘access’ here is both reading and writing.

Maxime.