Arthur Machlas wrote: > > Bob Proulx wrote: > >> With those in place you can work as yourself in those areas. Safer > >> than using root since as yourself you can't smash anything in the > >> system directories /etc or /bin or /var or other system locations. > > Isn't there a risk in granting user access to src, adm, and such if > ever your user account is compromised? There is always a risk associated with *everything*. The only truly secure computer is one that has had the following procedure applied to it. http://www.roseweb.de/caro/pages/security/v-one/cut-orig.htm > My uninformed opinion is that it's a question of relative risk; the > 'risk' involved in building kernels as root, versus the risk > involved in giving access to these dirs and tools should your > account become compromised. My experience is that accidents cause problems much more often than active intrusions. Security is certainly important. But more important for me is to create an environment that enables productive use of the system while limiting the risk caused by accidents from authorized users. Safety nets against accidents are very useful. If you are yourself (non-root) working on a tool that you own in /usr/local/bin/foo and while testing make a mistake and get a message that you can't read/write/remove a file in /etc when you meant /usr/local/etc then there isn't any harm done. You know what you did and that it isn't a problem (since you are non-root and have no permissions to /etc) and you fix your error and move on. But if you are root and the same occurs you won't get a permission error but instead will have modified the underlying hosting system. You might not even know that you had done so. This is not about intrusion detection but one of accident prevention. But accidents happen much more often than intrusions. Bob
Attachment:
signature.asc
Description: Digital signature