If I may be permitted to toss 2p in here. These groups were created for a good reason, which is that it's good security practice to reduce the amount that has to be done by root.
The fact that certain things can only be done by root is widely acknowledged to be a major failing of the traditional unix security model, which is why we have things like Capabilities stuck on top to try to mitigate it. Judicious use of groups is another way of reducing the necessity for root, and one that Debian has pursued well in my opinion. Paul Szabo's suggestion that if we just audit code then everything can run as root and be safe is just not realistic. Even audited code has bugs. Using sgid rather than suid binaries is an important harm-reduction principle for when holes appear, as they always will appear. For all the talk about groups being "root equivalent", the fact is that they are only root equivalent under a very narrow set of circumstances or series of events. They are therefore nowhere near equivalent to actually getting root. I for one do not want to see these groups being abandoned in favour of a return to the bad old days of needing to su root to do anything. The more that is done as root, the more likely that there will be big, root-now-on-every-system security holes, rather than small, just about possible in some setups, root-later-if-you're-lucky holes. You need to consider the balance of risks over the whole system. Having group staff on /usr/local allows local software to be installed without being root, which significantly reduces the potential harm that may be caused by software from untrusted sources (you should always audit all software before installation... reality check anyone?), as well as the harm from errors that has already been mentioned by others. alias rm="rm -i" is totally insufficient (and considered harmful because people come to rely on it.) There are myriad other ways in which errors or malice can strike, so we should *use* the unix groups and permissions system (imperfect as it is), rather than abandoning it and using root for anything that requires a modicum of privilege. I'm in favour of the original proposal to alter root's PATHs and library search order -- these make sense for the same reason as not having dot on the PATH. Dropping groups as per what Paul seems to be suggesting would make security worse, not better. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
