I believe this breaks down into a few closely interrelated questions, which are answerable with a reasonable degree of objectivity.

Why does Ubuntu allow different kinds of permissions to be adjusted for different users and groups of users? Is this high degree of configurability really necessary?

Almost all currently used operating systems, including Windows, have this functionality. Actually, on Windows the system is more complex, because Windows uses access control lists for almost everything while Ubuntu uses the simpler system of Unix-style ownership and permissions most of the time (but also supports access control lists).

A few reasons this is necessary:

1. If you want your computer to be accessed by users other than yourself, you need the ability to decide that some files are totally off-limits to certain users, and that others are readable but unmodifiable by certain users.

   Remember, this includes people who you might want to access your computer over a network. Such as yourself. Many people want to be able to share files between computers at home, or with their friends, but not with just anybody who happens to be using the same public wireless network. Thus users represent more people than you might actually have physically using your keyboard.

2. The operating system you're using--Ubuntu--is the same OS as Ubuntu Server. They have different packages installed by default, and different installers. You can transform a server system into a desktop system and vice versa. A full system of ownership and permissions is necessary for most servers, even if it may not be necessary for some desktops. The desktops work fine with it; the servers would not work without it.

3. User accounts can represent real people who access your computer, but they represent a whole lot more than that, too. A user account represents a collection of abilities. Special user accounts exist for performing particular tasks with constrained abilities.

   The purpose of this is twofold. First, the developer of the software, or the user, could make a mistake resulting in the software attempting to perform some action that can be known beforehand could only cause harm.

   Second, a malicious party might deliberately fool the software performing the specialized task into doing something bad, like destroying data or allowing the malicious person to control it.

   In both of these cases, harm is often reduced if the task is performed by a non-privileged user that doesn't represent any particular human user of the computer, but exists just to perform that particular task.

   If you only have a few human user accounts set up on your Ubuntu system, then most of the user accounts listed by running cat /etc/passwd are this kind of "user." (Don't worry, running cat /etc/passwd does not actually show you people's passwords; the file is called that mainly for historical reasons.)

What's the point of Ubuntu limiting my user account's access to anything, if I'm an administrator and can perform any action as root with sudo?

The same reason there are guard rails on the sides of some roads, manhole (personhole?) covers, a cover over the needle at the end of a syringe, safeties on firearms, etc. And not for the same reason that people put locks on their doors. Not to keep you from doing something deliberately that you do want to do, but to keep you from doing something accidentally that you do not want to do.

When you want/need to perform an administrative task, it is important that you be able to do it easily. Your control over your own machine must be respected, plus a system that's unnecessarily hard to use is not very good. If Ubuntu prevents you from easily performing administrative actions, that is a bug. Fortunately, this is not usually the case (though I fear we're moving in that direction). One of the reasons Ubuntu uses sudo is that it generally facilitates easily running commands/programs as root, without reducing your ability to perform ordinary, non-administrative actions concurrently.

When you're not trying to modify your system in some deep way that could be dangerous, it is similarly important that the system be designed in such a way as not to fool you into doing it.

Similarly, you probably have the right to give your life savings to some random guy. You also have the right to play tennis. Your autonomy is important; it is because of that and not in spite of it that a "give away all my money" button on your tennis racket would be a bad design.

For more information about why even administrators should use "limited user accounts" (plus the ability to perform any particular action without limitation, on demand), see:

• How to NOT become a root user? Are administrators root?

I understand what user permissions are--they are permissions for the file's owner. What are group permissions for?

The owner of a file--which is usually the user who created it, or the owner of a special folder that's set up so files created it in belong to that user--can choose a group of users to "group-own" the file.

This group of users can then be given special abilities (or potentially, have special abilities taken away, though that's not generally recommended or effective) compared to everyone else.

By everyone else I mean all the other user accounts on your system, other than the file's owner and group-owner. This includes the ones that don't correspond to any human being. For example, you might want all the people who use your computer to be able to configure printers (lpadmin group) and use the CD/DVD/BluRay drive (cdrom group), but there's probably no need to allow the crash-reporting "user" (whoopsie) or the clock-syncing "user" (ntp) to have these abilities.

You can use groups to manually implement access control if you like, but on desktop systems, often most groups are automatically configured and managed. The groups command will list all the groups you're a member of.

What are "other" permissions for?

They apply to everyone else--to user accounts that neither own the file nor are members of the group-owner.

Are group and owner file permissions just for servers?

No, they are used to manage distinctions between different kinds of user accounts on your machine, including non-human "user" accounts. This applies even if there is only one human user account on your system.

For example, membership in the adm group (which does not make a user an administrator) confers the ability to read the contents of most systemwide log files. This is a relatively harmless ability for just about any human user of most desktop systems, but could potentially lead to problems if it were conferred to part of the system that perform only a highly specialized task (that is, it performs only that task unless something like a partially successful cyber-attack is perpetrated).

Are group and user file permissions more important on servers than desktops?

Sort of.

On servers you are more likely to have to be aware of them and manage them manually, because you are more likely to deliberately provide and deny access to a variety of resources for a variety of human users.

But they are necessary for the system to work correctly even for a single human user. The system would have to be designed quite differently to work well in a single-user mode for everyday computing, without a system of file ownership and permissions.

By way of comparison, consider I/O scheduling. Many server environments have many more processes accessing many more files than many desktop systems. Therefore, input-output scheduling (managing how limited throughput can be managed to complete file access transactions with reasonable efficiency) is especially important on (some) servers, compared to (most) desktops. Server administrators are more likely to study I/O scheduling and to make changes to the way it works on their computers, than most desktop users. But I/O scheduling is necessary for either a server or desktop system work.

As the owner of a file, I can change all its permissions and as well as its group-owner. I can do this without sudo or a similar mechanism! So what's the point of permissions?

The owner of a file can do this without being root (i.e., without sudo), but other non-root users cannot. This includes the non-human "users" that are part of the system (see above).

Furthermore, many files on the computer are not "owned" by your user account. Those files do require that you authenticate in some way, to modify their permissions. You do have to use sudo (or a similar mechanism) to change permissions on system files owned by root.

Finally, there is some value associated with having permissions that apply only to you, even if you can change them without using sudo or any similar mechanism.

What are user permissions for? Why would I want to change what I can do with a file, when I can just change it back?

For the same general reason you may want to make a file read-only (even though you can override it yourself), you may want to make a file that you cannot read or execute (run).

The more common situation is that you may not want a file you own to be executable by you. When you download something, you probably don't want it to be marked executable because it could be malware. You probably want the opportunity to consider if you want to run it, before marking it executable. Furthermore, if you downloaded a file whose name ends in .pdf but is actually a malicious program, you definitely don't want execute permissions to be set on it by default.

There is another reason that's less related to security. Any file marked executable is treated as something that can be run--a program or script. Most files are neither, and you would not want to be given the opportunity to run them.

For example, if a text file is marked executable (for example, you own it and it has the execute permission turned on for its user-owner) and you double-click on it in Nautilus (the file browser), it will run. But most text documents are not scripts, and you don't want to try to run them when you double-click on them; instead, you probably want to open them in an editor.

It's less common to want to create a file that you cannot yourself read (without changing its permissions back). One situation where you may want to do this is if you had several files and wanted to avoid opening one of them for a while, for example if it is huge and takes several minutes to open. I've been in this situation, where I had to keep waiting for an application to finish opening a file so I could close it because I'd selected the wrong file (again).

A related possible scenario is if you are automatically performing some action on many files (a "batch" job) that reads from the files, but you want it to skip some. Provided that the action will "degrade gracefully," continuing to do what it can after an error, the easiest way to accomplish it might be to mark the few files you want to skip reading as unreadable.

A very different situation is: maybe you want to deny read permission to yourself on some file because the file serves some purpose other than containing data. Files can be used to signify some condition. As a made-up example: some search application that indexes files might first check to see if a file called noindex is present in your home folder, and stop if it finds. That file doesn't have to be read; arguably, marking it unreadable helps clarify its purpose.

Wanting to keep yourself (or some task you're performing as you) from reading files you own is not a particularly common situation, though. And in practice, most "signal" files (that exist because their existence itself means something) are readable by their owners. Really, as far as I am aware, there are three primary reasons for the user-owner of a file not to be able to read it, and even to be able to write to it without reading it:

1. Group and other have read, write, and execute bits, and they can take on any combination of values. There is no compelling reason to break with this model--thereby making the system more complicated--for the user who owns the file.

2. Many resources that we don't usually think of as being file-like are represented by entries in the filesystem. For some resources, it makes sense to write to them, but does not make any sense to read from them. For these resources, the read bit is sometimes turned off for everyone, even the owner, and even if the owner is root. (Not always, though; for reasons that are both beyond the scope of this answer and at the edge of my own knowledge, some write-only devices' filesystem entries still have their read bits enabled for some users.)

3. The ability for a file to deny read access even to its owner is sometimes used to represent files on a write-only filesystem. (Not always, though; it depends on the details of the filesystem and how it is mounted.) Write-only filesystems are uncommon but they do exist and have practical uses.

Here's a summary that I have gathered:
Usage: chmod <number> <filename>

• chmod all files to 644
• chmod all .htaccess files to 644
• chmod all robots.txt files to 644
• chmod all directories to 711
• chmod all directories with directory listing (.htaccess Options +Indexes) to 755
• chmod all directories that users can upload files to, to 755 (ex: /uploads/).

Explanations:

• 644 means:
  • 6: the owner of the file/directory can read and write, but not execute. Since files are not executable, you don't need to have "x" rights here (6 means r+w. 7 means r+w+x).
  • 44: The group that the file/directory belongs to (see the group by using ls -l) and everyone else (the public) are able to read the file, but not execute or write to it (permission number 4).
• 711 means:
  • 7: the owner of the file/directory can read, write, and execute. This is needed for directories! Without "execute" when you try to list the directory you'll get permission denied.
  • 11: The group that the file/directory belongs to and the public have execute rights only. This is suitable for directories where you don't want other people browsing through the contents but do want to give them access to selected files further down the directory.
• 755 means:
  • 7: the owner of the file/directory can read, write, and execute.
  • 55: The group that the file/directory belongs to and the public have read and execute permissions but not write. This allows users to be able to view what files are in a directory, and be able to read those files, but not alter them.

There's also an interactive online calculator you can use to figure out what permissions to use: https://chmod-calculator.com/

Greg mentions attrib - but attrib isn't anywhere close to chmod - attrib can set Read-only/Hidden attributes of a single file - it doesn't provide fine-grained controls like icacls does.

icacls sets/resets the access control lists, so you can grant/deny rights for individual SIDs & groups. It is fairly complicated though.

Here's an example I have saved in my github gist; it resets the ownership and access control list for all files in a folder and is particularly useful to fix those annoying "You need permissions from .. to perform this action" especially when moving files over from a previous install:

icacls * /reset /t /c /q 

Here, we have that

• /reset replaces the existing one with the default list.
  
• /t acts recursively on all files, folders & subfolders
  
• /q doesn't display any success messages
  
• /c continues with remaining files even in an error occurs.

You can also do things like backup the existing ACLs & apply them across all. Have a look at ss64 which explains the different options & switches very well.