> I just find it odd from a practical view point that kern.nosuidcoredump > no longer applies, though understand from a security view point that one > would want to avoid slip ups by the developer between setuid and seteuid > or in forgetting to restore the setting to a secure mode after debugging.
Sorry, but that underestimates the danger. A process which has operated as multiple uids _always_ is doing so because it is mixing up domains of operation; it has some capability which it is trying to hide or block. Some capabilities are sockets or ports or such which only root or some other uid could open but which can continue to be used afterwards, but the other type of capabilities represent themselves in memory, and are typically a secret, even if only by the addresses of the block of data. Such memory should never end up on disk, in a file. It is easy to talk about more sophisticated models for turning such things on and off, and that's great, but then what do the other systems do with these fancy options? They leave them turned off. To avoid mails like yours. So nothing is gained. Instead, as a group our policy is to turn these things on, not make it easy for them to be turned off, and thus enforce the policy strictly, and thereby we educate people using these functions to get used to the choices they should be making in security software. If we don't make them aware, they will remain blissfully aware and think they are smart enough to write setuid or daemon software.
