There's not really one correct answer to this question. It's a trade off between security and usability.
run command with pkexec each time ( which I kind of want to avoid for the sake of user experience );
If the intended audience does not have "CLIphobia", sudo
could be really great here if "each time" is within 15 minutes.
But from a security point of view, I'd recommend pkexec. I assume it can be trusted as it comes pre-installed with the distro, unlike some quickly hacked up setuid wrapper or daemon.
since the indicator is in python, I could have a binary with setuid bit set written in C. However, I've been told this approach is frowned upon;
The only problem I have heard of with setuid wrappers is that they can overwrite themselves with a trojan if they exploited, but this is not relevant for setuid-to-/root/ binaries as any exploit on a process running as root means you're screwed anyway.
The only problem I have experienced does not apply to setuid-to-/root/ binaries either, it was so that I did not understand all of unix user ids and forgot to set the real user ID, saved user ID and their group ID equivalents, this meant that a program that /drops/ privileges can still gain them back.
There could be other reasons why setuid wrappers are frowned upon, but I haven't heard of any. If no one else can find reasons why setuid wrappers are frowned upon, a setuid wrapper will be a really good choice.
start a "proxy" which will run as root and only perform that one specific task , and the indicator will communicate with that "proxy"
If you create a daemon to do the task, keep it as simple as possible and make sure that unauthorized users don't get to communicate with it.
I can think of two options: (1) use a password that an authorized client would know, the daemon does know and an unauthorized client does not know. The password would have to be stored in a file chmoded 400 and owned by root.
(2) use unix permissions on the socket to prevent any other local user to even try to (ab)use the daemon.
https://stackoverflow.com/questions/20171747/how-to-create-unix-domain-socket-with-a-specific-permissions
Option two can be considered less secure and more inconsistent at UX. The user might not understand why it won't work when they're logged in as a different user which is really bad when it does happen.