Spot on. This is also why daemons which need to bind to low ports start as root but then switch to a non-privileged user after accomplishing that. Anything else introduces a serious security issue. Expecting any user to run a user application as root is just so wrong on so many levels, quite apart from the assumption that a normal user has root access.
Actually, in Debian at least there's been some "give and take" over the last few years.
There are two commands which users expect to be able to run but which demand elevated privilege: ping and traceroute. In the past I've noted that one or two releases allocated a capability to the binaries that allowed them to get the resources they needed without running as root, but then the distro reverted to running them setuid root: my own suspicion is that the amount of grief caused to standard backup etc. procedures outweighed the elegance. Note that at no time did these programs demand a password from the user.
I've used POSIX capabilities fairly heavily on a couple of occasions, but particularly over the last few months when I've been porting a program that used low-numbered UDP ports, created a unix-domain socket in /var/run and various other things. It's possible to integrate the initial capability manipulation into the IDE's compilation commands, /but/ since the capabilities are stored in filesystem extended attributes they're lost if you tar a file or move it around: I suspect that this was a conscious decision on the part of the kernel developers.
There's not an option to set capabilities with the standard install command, neither is it able to invoke an external command to handle that sort of thing. The way I worked around the problem was to have the program announce what commands were needed to get things set up properly if it realised it had a problem, at that point I had to use sudo to sort things out but that was only needed when I loaded an updated version.
Obviously in at least some cases there's other possibilities which exploit egid etc.
MarkMLl