Yes, those programs deserve to lose, and the programmers deserve to have
the fleas of a thousand camels infest their armpits. However, it is the
users of those programs that pay the price, not the programmers, and it
is not fair for us to cause those innocent users to lose.
Programs like this which initially run suid something
ought to be rare and should be easy to fix.
You're right; it would be very easy to fix the program.
The problem, though, is that we can't guarantee that everyone who takes
a new kernel version will pick up and install the new version of this
Very Popular And Commonly Installed Program. A user who grabs a new
version of the kernel, thinking they are getting new features, will be
very upset(*) if they discover that by grabbing a new version of the
kernel, they opened up a new security hole which we knew about but
decided to deliberately put in anyway. New kernels should *close*
security holes, not open new potential ones!
You may say that I am being paranoid --- and I am. However, who would
have thought that a program like splitvt would become an instant root
backdoor? Only someone who is paranoid. Security is like that; you
have to be always vigilant, and always conservative.
Bottom line --- sure, we can add new system calls with new semantics, if
we think they have a sound security model. But changing fundamental
semantics of old system calls, especially security related ones, is
madness. The operating systems which did this have learned that it is a
stupid mistake and I'm working with one of so that they help make
setreuid() be more like Linux's current implementation. So why should
we go off and make the same mistake that they are now recovering from?
- Ted
(*) Have you ever heard of the word "liability"? Find a good tort
lawyer; he'll tell you all about it. It's related to another really
good "l" word --- "lawsuit". :-)