That's mad idea - keep similar things in one place! starting programs is done in kernel and nice-value-support is also done in kernel!!
You could wrap /lib/ld-linux.so, and get all dynamically linked
programs done in one sweep.
Yes, but compexity of 'sh -c /some/command' is uncomparable to one of shell-level-program-renicing system. such system should keep database of reniced processes, parse it (using awk or sed, i'm afraid...) and then renice process (what also takes two files[!, they are in fact one-liners, but it is needed to gain root privileges to renice process]). sorry, but linux works smoothly on 386, and such mess would surely change it.
Using a shell to run external programs is quite common. The system()
and popen() functions both invoke the shell.
What can? the only account that have access to renicing field is root. if some-malicious-person can gain access to root account, he does not need renicing field, because he can renice processes by snice tool! for normal user, this field is unchangeable. of course, if root is so <....> to set inpropertly nice field, he is propably also about to set setuid to /bin/[ba]sh and set root's password to '123'... I really do not see any dangers of providing such feature in kernel (b[u]y the way - renicing in user space requires root privileges, so [from security point of view] it doesn't really matter where renicing is done - both in kernel and userland it has full-access to the system)
I'm not so sure it belongs at all. The can of worms it opens up is a
bit too big, IMHO.