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.
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.