> (2) Losing the command name isn't good; lots of people turn process > accounting on for logging (in fact, I'd assume 99.9% of people who > turn process accounting on use it purely for logging) and it > substantially decreases the utility if it's easily circumvented.
Isn't the command name easy to lose and/or forge already, with links if nothng else? In any case, it seems to me this is one reason to make fexecve() optional. (I'd actually _like_ to see something capabilityish, in which case "can use fexecve" would be a capability that could be removed, from init if need be, on systems that care about this sort of thing.) > (3) Setugid processes should be prohibited, or at least setugid > dynamically-linked processes, because otherwise there's a window > where a live update of a library might be used to run the old binary > with a new set of libraries. How does fexecve() make anything possible here that wasn't possible before? It seems to me that updating .so libraries has always carried this risk, so I must be missing something. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B