On Tue, 31 Oct 2000, Bud Rogers wrote: > I think it could be argued that those changes are not necessarily good > from the standpoint of system security.
In the modern world, sbin really does mean "system" binaries. The division between "things you need to fix a crashed system" and "things for ordinary use" is made by whether something is in /(s)bin or in /usr/(s)bin. It does not have really much to do with security. Ordinarily sbin is not in an average user's path because there is not much an average user can do with the stuff in there. I don't know of any modern Unix system in which the programs in sbin are actually not accessible. It doesn't really matter because you have to assume that any user has access to the source code for basically every tool (especially on Linux!), and you can't really count on restricting access to an executable as any form of security. I actually think that Linux tends to have the best-organize tools. Those that have to do with system administration are in /sbin, and those that are intended for use by normal users are in /bin. Those that are always needed are in /sbin or /bin and those that are needed only for normal use are under /usr. I also question the historical accuracy of 'sbin' as "static binary" - Unix has always had /sbin, but it hasn't always had dynamic linking.
