I agree. That file is not supposed to be edited by the user or by applications, that's why nobody has even tried to make it easily editable by applications (otherwise it'd have been a "privileges.d"-style folder where each application can install a list of required privileges as separate file).

There will be a proper permissions system in place, we're just not there yet. And yes, for Harbour, the current way is restricting access by default and then only explicitly granting permissions.

If you don't go the Harbour way, and really wanted to solve this somehow *right now*, you could e.g. have a postinst/prerm scriptlet that adds/removes your application binary file to the permissions file. That's still hack-ish and might require reinstalling of your application after a system upgrade.

Yes, that's coming. On the other hand, I'd argue that it's also not okay if every Harbour application would get all permissions (accessing contacts, etc..) by default without asking you. So for now, you kind-of can grant access to any such application manually already (by editing the privileges file as root), but not yet through some nice UI means.

Once a proper permissions system is in place, of course Harbour apps will be able to make use of it (and through that, get access to contacts if the user wants the app to get access to contacts).

By the way, with developer mode enabled, you can use "devel-su --privileged" to get a setgid privileged shell. For non-Harbour apps, you could have a setuid root helper that does setuid(nemo) + setgid(privileged) and then runs your application, which would also make it work. The implementation is left as an exercise to the reader.