There was discussion a few weeks ago where somebody asked how to temporarily give a program root permissions so that it could access a serial port, and the universal response was to run it in the dialout group or something roughly comparable.
I've got a variant of that where I think it is legitimate to ask the Lazarus IDE to run a specific part of a build sequence as root, and I don't see any easy workarounds. Unfortunately, it's getting progressively more difficult to do this.
On Linux, there are some things that explicitly need root access rights, such as creating a socket with port < 1024 or creating a temporary file (e.g. a FIFO endpoint) in /var/run. There's a finer-grain approach available than attempting to run a GUI program setuid root (which is actively prohibited by some widgetsets) or mandating that the user be root when he starts it, which is to use POSIX capabilities to mark the binary as having certain inalienable rights. For obvious reasons, this marking operation needs temporary root privilege.
For the last few versions of Debian, I've been able to set capabilities using something like this at the "execute after ... command" stage:
/bin/sh -c "(kdesudo -n setcap CAP_DAC_OVERRIDE,CAP_NET_BIND_SERVICE,CAP_NET_RAW=p+e Watchxxx-$(TargetCPU)-$(TargetOS)-$(LCLWidgetType))"
Those two capabilities allow writing to root-owned directories and allow creation of low-numbered sockets respectively, without running the program as root or attempting to run it setuid root. It is possible- and considered good practice- to relinquish the elevated capabilities as soon as the relevant operations have been completed during startup.
Because this prompts the user for his password as authentication and requires that he is authorised by being a member of the sudoers group etc., it offers far more precise control than trying to run the IDE or the setcap command as root... which is also what would effectively happen if the polkit mechanism were used.
Unfortunately, in order to use kdesudo with the current (Buster, "Stable") version of Debian, one has to copy it from an older one (Stretch, "Old-stable"). This will no longer be possible with the next one (Bullseye, currently "Testing") since the prerequisite library packages no longer exist. I anticipate that this will affect Ubuntu (as a Debian derivative) and other distreaux.
In principle, it should be possible to replace kdesudo with sudo -A -k, but I'm having enormous difficulty getting this to work: it needs an /etc/sudo.conf file which sudo insists contains syntax errors, and so far I've had no success with alternatives like getting xdg-open to run a .desktop file which in principle at least can specify the user it's to run as.
Does anybody have any suggested workaround? The existing situation using kdesudo is one that works well, and I suspect that this is something which is going to be needed increasingly as more runtime environments required signed binaries etc.
Slightly later: I've got sudo -A -k working, the magic appears to be to use a standard text editor to create/modify /etc/sudo.conf and then to use visudo to make a trivial change to the sudoers list which also forces the internal state to be updated. It still feels a bit fragile.
It appears that sudo also has -S and -u options to allow a password to be piped and specify which user is to be run. I suspect that those would be enough to add a general "Run as..." facility for the final build command for unix-type OSes, I seem to recall that some versions of Windows had a "Run as" program as an optional extra which did much the same as sudo.
MarkMLl