After some more thought, I'm pretty that we don't want to authorize any absolute path for templates.
For one, I'm almost sure it's a security all waiting to be found. Letting the possibility for one to use any file on the FS, especially one with unpriviliedge rights, as a template for root-level management of nodes seems to be a bad idea.
But even without considering the extension of the attack surface, allowing to use template anywhere on the FS completely broke the boudaries of our system, and it becomes impossible to even try to versionned (or take care of version) of Technique templates, because we can't any longer tell when some technique come into Rudder. Today, we DO can, even if we are not doing it completelly: the Technique template is versionned in our Git. And we do use it, because it's what allows to trigger a promise generation if a Technique changed and the library was reload (or more exactly, it allows to trace which Techniques changed, and so what promises must be updated).
So, the problem may be tell like that: we don't want to authorise template outside of our Git.
Notice that all of that MAY be irrelevant for the <FILE> tag (see #7402), because we can have as policy that <FILES> are outside of Rudder system, and that it's a feature to not track them - but that's not clear, see details on the ticket)
So, I propose to add that prerequisite: the absolute path given must be a subdirectory of the Git defined in the rudder configuration file for property "rudder.dir.gitRoot" (by default, /var/rudder/configuration-repository)