Root privilege
| Line 1: | Line 1: | ||
This is a seperate entry because -- surprise -- you don't have to be [[root]] to run programs (or for [[daemons]] to run themselves) as root in order to have root privilege. Any daemon, user or group that has a [[uid]] or [[gid]] of 0 runs as [[root]] effectively. So anyone that hijacks an account that has a root uid is effectively root. Which is why it's a good idea to run as few programs as possible that do that. | This is a seperate entry because -- surprise -- you don't have to be [[root]] to run programs (or for [[daemons]] to run themselves) as root in order to have root privilege. Any daemon, user or group that has a [[uid]] or [[gid]] of 0 runs as [[root]] effectively. So anyone that hijacks an account that has a root uid is effectively root. Which is why it's a good idea to run as few programs as possible that do that. | ||
| + | |||
| + | Denying the right to use [[su]], and therefore unlimited root privilege, from a regular user account is more secure for work that doesn't need root privileges in unpredictable ways; root can make scripts for that user to still be able to do predictabled root-privilege tasks as needed. Root is harder to hack that way if that user is compromised by a hacker or malware - assuming the simple user isn't permitted to edit the scripts, which is a common novice oversight. | ||
| + | |||
[[Category:FreeBSD Terminology]] | [[Category:FreeBSD Terminology]] | ||
Revision as of 13:32, 17 January 2005
This is a seperate entry because -- surprise -- you don't have to be root to run programs (or for daemons to run themselves) as root in order to have root privilege. Any daemon, user or group that has a uid or gid of 0 runs as root effectively. So anyone that hijacks an account that has a root uid is effectively root. Which is why it's a good idea to run as few programs as possible that do that.
Denying the right to use su, and therefore unlimited root privilege, from a regular user account is more secure for work that doesn't need root privileges in unpredictable ways; root can make scripts for that user to still be able to do predictabled root-privilege tasks as needed. Root is harder to hack that way if that user is compromised by a hacker or malware - assuming the simple user isn't permitted to edit the scripts, which is a common novice oversight.
