A big part of it comes from the security model and Linux historically being a multi-user environment. root owns the root directly / which is where all of the system files live. A normal user just has access to their own home directory /home/username and read-only access to things the normal user needs like the /bin where programs are stored (hence /bin/bash in lots of bash scripts, it tells the script what program to run the script from)
Because of this model, a normal user can only mess up their own files, while root can mess up everyone’s files and of course make the system non-bootablem. But also you can have user Bob signed in and doing stuff but unable to access user Alice’s files, and user Alice can be doing stuff and even running the same programs that user Bob is running (since it’s read only there’s no conflict) and then the administrator can log in as root to install something because they got a ticket to install suchandsuch for soandso.
Back to your point with sudo, sudo is Super User Do, so you are running a single command as root. By running it as root you can potentially be messing up with Alice and Bob might be doing, and most importantly whatever you are running with sudo can potentially affect any file on the computer. So if you run the classic rm -rf / it will delete every file that the user has write access to, so if bob runs it it’ll delete all of /home/bob/ but Alice will be unaffected, and the admin can still log in as root to do stuff. But if you run it as root you’ll quickly find the server unable to boot and both Alice and Bob will be very upset that they can’t access the server or their files
If you host a website you’ll generally take advantage of this by giving the www folder read-only access so that web users can only see webpages and can’t start reading random system files, or for server software you can create a dedicated user to run that server software as, so if someone were to somehow exploit a vulnerability and gain access to that server user they can only mess up the software and no system files
A big part of it comes from the security model and Linux historically being a multi-user environment.
rootowns the root directly/which is where all of the system files live. A normal user just has access to their own home directory/home/usernameand read-only access to things the normal user needs like the/binwhere programs are stored (hence/bin/bashin lots of bash scripts, it tells the script what program to run the script from)Because of this model, a normal user can only mess up their own files, while root can mess up everyone’s files and of course make the system non-bootablem. But also you can have user Bob signed in and doing stuff but unable to access user Alice’s files, and user Alice can be doing stuff and even running the same programs that user Bob is running (since it’s read only there’s no conflict) and then the administrator can log in as
rootto install something because they got a ticket to install suchandsuch for soandso.Back to your point with
sudo,sudois Super User Do, so you are running a single command asroot. By running it as root you can potentially be messing up with Alice and Bob might be doing, and most importantly whatever you are running withsudocan potentially affect any file on the computer. So if you run the classicrm -rf /it will delete every file that the user has write access to, so if bob runs it it’ll delete all of/home/bob/but Alice will be unaffected, and the admin can still log in asrootto do stuff. But if you run it asrootyou’ll quickly find the server unable to boot and both Alice and Bob will be very upset that they can’t access the server or their filesIf you host a website you’ll generally take advantage of this by giving the
wwwfolder read-only access so that web users can only see webpages and can’t start reading random system files, or for server software you can create a dedicated user to run that server software as, so if someone were to somehow exploit a vulnerability and gain access to that server user they can only mess up the software and no system files