Re: [RFD] 'nice' attribute for executable files

[Wiktor <victorjan@poczta.onet.pl>]

Måns Rullgård wrote:
> You could wrap /lib/ld-linux.so, and get all dynamically linked
> programs done in one sweep.
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!!

> Using a shell to run external programs is quite common.  The system()
> and popen() functions both invoke the shell.
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.

> I'm not so sure it belongs at all.  The can of worms it opens up is a
> bit too big, IMHO.
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)

thx for replies

--
wixor
May the Source be with you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/