I am new to Ubuntu and I used to do everything on Windows. As much as I know Windows has "read only" file option for the user. However, in my opinion, Ubuntu allow the user to manipulate file permissions excessively.

drwxrwxrwx 2 ttt ttt 4096 Tem 24 13:04 dante

  • There are three groups of user; owner, group and other respectively.

Normally the one who creating the file is the owner. Then who are the "group" and the "other". Is this used more for server like systems where there are many user?

Even if this is used for security issues, without "$sudo" it can be easily change to whatever wanted.

Can you also suggest any further reading?

It may be possible that I am exaggerating "chmod", but still I will thank you if you answer.

  • This site prefers that you ask specific questions. " However, you write in my opinion, Ubuntu allow the user to manipulate file permissions excessively." Are you requesting people to offer their opinions?
    – user25656
    Jul 24 '13 at 11:19
  • While I agree this is a bit broad, it does seem to be asking why file permissions are so granular in Ubuntu and if some file permission functionality is irrelevant to desktop users. That seems like an objectively answerable, narrowly scoped question (or, strictly speaking, two very related such questions). I've written an answer to address this and I recommend against closing this question (though some edits may be quite appropriate). Jul 24 '13 at 13:39

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:

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.

  • Ehem...and I tried to strip down my answer =D. +1 for taking the time to type all of this up.
    – Alaa Ali
    Jul 24 '13 at 13:42

Normally the one who creating the file is the owner. Then who are the "group" and the "other". Is this used more for server like systems where there are many user?

In Linux, a file (or directory) can be accessed by three different "entities".

  • The user (owner) of the file.
  • A group, which (just like the name suggests) is a group of users.
  • All the other people; so basically everyone else (i.e. not the owner, and not in the group).

Each of these entities can either have read, write, and/or execution permissions on a file. See the flexibility and simplicity of Linux? Three entities, each with three different permissions. This provides a more flexible way of granting permissions to files/folders. Is this used more for server like systems where there are many user? Well, yeah okay, you can think of it that way. Your Ubuntu uses groups and others in many situations though, without you worrying about it, but I digress.

Even if this is used for security issues, without "$sudo" it can be easily change to whatever wanted.

If I understand correctly, I'm guessing that you used chmod on files in your home folder, and so you did it without the need of sudo. Let's take an example:

-rwxr-xr-x 2 alaa test 4096 Jun  5 10:02 fileName

If you want to understand what this whole line of output means, see this.

alaa is the user (owner), and test is the group of the file.

Now, the command you're talking about, chmod, is used to change the permissions of a file. So, let's say that I want to give write permissions to the group test, I would do the command:

chmod g+w fileName

Meaning: for the group entity (g), add (+) the write (w) permission to the file fileName.

I, the user alaa, can do this command without needing sudo, because I'm the owner of it. If I were not the owner, I would not have been able to do this, and I would need sudo to do it.

Can you also suggest any further reading?

I suggest you, not to read about the command chmod, but to read more about the Linux/Unix File Permissions. You can visit these short pages for starters:


one of the first places for help is "man". You can write "man chmod" and you will get all information about the usage of the command.

The command changes the who can access the file and what he can do with that. "r" stands for read, "w" for write, "x" for execute. There is a "rwx" tupple for each of the following categories "owner","group", "others". If one category has only read rights ("r--") then they can only read the file. That means open it with an editor but make no changes whatsover. With ("rw-") one can change the file as well. With ("rwx") one can also execute the file if the file is executable. Now, is it possible for a file to be able to open it in an editor and to be able execute it as well? Well, yes. If it is a binary file and you open it with an editor you will not understand a thing and if you try to execute a simple txt file with just text you will probably do nothing. However if the text is a series of commands (script file) then it can do both as well. For those files it is very important to determine the access rights as one person can change something in the commands and later this file to be executed by some one else.

About the categories owner: the user that created the file. Ofcourse you can change the owner of a file with "chown". group: The group(s) of users the owner belonged to at the time the file was created. other: everyone else except the owner and the users of the same group as the owner.


A simple web search would give plenty of results for your question. For a quick overview, I recommend you to read this.

  • 3
    Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – Nanne
    Jul 24 '13 at 11:35
  • You are right, I will update my answer accordingly ASAP Jul 24 '13 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.