I rely heavily on aliases in my .bashrc and it crossed my mind that I could improve my privacy / security and somewhat harden my Ubuntu 20.04 Desktop by changing recursively the permissions of my home directory and of its subdirectories and files (600 for the files and 700 for the directories). And so I ran:

sudo chmod -R 600 /home/undoxed && sudo chmod -R u+X /home/undoxed

where undoxed is the name of my administrative user. The recursive flag has not spared .bash_logout, .bashrc, and.profile.

From what I earlier noticed when tinkering with /etc/adduser.conf, setting in it DIR_MODE=0700 along with setting umask in .bashrc to 0077 and then adding a new user with useradd results in 600 permissions of any file in the new user's home directory with the exception of: .bash_logout .bashrc .profile. The said three files got 644 permissions, instead of 600 as I expected.

Why is it so that these three files were spared? Could making these files 600, as did I manually with chmod -R 600, make my OS unusable? Could there be some other consequences of these files having such permissions when compared to 644?

So far everything seems all right but I've not rebooted after running sudo chmod -R 600 /home/undoxed && sudo chmod -R u+X /home/undoxed today and I'm anxious to do so.

  • 1
    These files are mostly sourced instead of executed. They don't normally have the execute permission set anyway.
    – Tom Yan
    Dec 7 '21 at 14:09
  • 6
    Never use sudo for files in your own directory! In this case, it simply isn't needed, but depending on the command, you could change the ownership of the files. Basically: never use sudo unless it is actually required.
    – terdon
    Dec 7 '21 at 15:25

TL,DR: .bash* can be 600, but chmod -R 600 is dangerous.

You can make your home directory accessible to only you:

chmod 700 ~

This doesn't need to be recursive. It's impossible to access a file without accessing a directory that it's in. For a directory, this means that it's impossible to access a directory without accessing its parent directory. So making a directory inaccessible (no x permission) makes everything under it inaccessible.

(There is one way to bypass the need to access the containing directory, which is to already have access: if a process already has a file open, it stays open, even if something changes that would now make it impossible for the process to open the file. Here “open file” includes having a directory as the process's working directory. The something that changes can be, for example, a permission change, or a move to a different directory, or the process reducing its privileges.)

There are a few circumstances in which you may need to keep parts of your home directory accessible to other users or to system services (e.g. making .plan accessible to fingerd or ~/public_html to httpd). They're uncommon nowadays when most people use individual machines which don't run any public services. In such a case:

  • Make your home directory traversable by everyone, but only readable and writable by you: chmod 711 ~
  • Make the content of your home directory private: chmod go= ~/* ~/.[!.]* ~/..?* (non-hidden files, hidden files except . and ..*, and hidden files starting with .. other than .. itself — ignore the error if one of these patterns doesn't match anything)
  • Allow read (r) access, plus execute/traverse (x) access for directories, to the specific files and directories that need it.

These permissions allow any local user to check whether a file by a given name exists (whether ls ~jerzy/somefile fails with “permission denied” or “no such file or directory”) but not to list the files in your home directory.

Configuration files for programs that you use, such as bash, don't need to be public. The only processes that need to access them run on your account. You can chmod 600 ~/.bash* if you like. It won't make any practical difference if your home directory is only accessible to you anyway, but it won't hurt.

If you set your umask to 077, all your new files will be only accessible to you.

Do not run chmod -R 600. As root, this can make your system so hard to restore that reinstalling is easier. As a non-privileged user, it's easier to recover from, but still painful.

chmod -R 600 removes execute permission from directories, and for a directory, the “execute” permission (the x in chmod, bit 1 in numerical values) means the ability to access file in that directory. The “read” (r, 4) permission only allows listing files in the directory. So chmod -R 600 ~ forbids everyone, even you, from accessing files in your home directory. Then chmod -R u+X ~ restores execute permissions for directories, but only if the system hasn't crashed in between.

Furthermore the sequence removes execute permission from all regular files. Some regular files need execute permission. This obviously includes any independent software that you may have installed in your home directory, and personal scripts or other programs. This can also include files that aren't generally thought of as directly executable; for example, older versions of Ubuntu used the execute permission to indicate that certain kinds of files were trusted, including .desktop files (though newer versions don't use this mechanism anymore).

The sequence also makes all files writable. It can be useful to make some files read-only, for example important files that you wanted to avoid overwriting or deleting accidentally. Many version control programs make certain files read-only because they're internal state files that normally never change, or to indicate that users aren't supposed to change them directly, or to indicate that a file is locked. However, this is rarely critical.

(Incidentally, there are a few files that must be private, such as SSH keys. A recursive chmod in your home directory that adds non-user permissions would break this, and in particular could make it impossible to log into your account over SSH.)

If you want to make all your files private individually, don't change the permissions that apply to you.

chmod -R go= ~
  • 2
    It might be worth mentioning that certain standard files require specific permissions (e.g. ~/.ssh/id_rsa needs 600). Granted, I only know of cases where what it needs is exactly what the OP happened to have run, but as a general rule, that's one more reason why blindly running recursive chmods isn't a good idea.
    – terdon
    Dec 7 '21 at 15:28
  • I did give 700 to some of my files and directories (containing my scripts and non-critical software as cryptocurrency nodes) after having executed: sudo chmod -R 600 /home/undoxed && sudo chmod -R u+X /home/undoxed. For the sake of brevity I didn't mention it in the question. After the change of permissions /home/jerzy/.cargo/bin/cargo refuses to do anything (Permission denied (os error 13)) although all the files in ~/.cargo/bin have been given 700 and ~/.cargo/ have been given 700 and all the other (nonbinary) files in ~/.cargo had been given 600 .
    – John Smith
    Dec 7 '21 at 18:43
  • 5
    The suggestion that "It's impossible to access a file without accessing the directory that it's in" is an unfortunate approximation. Files are not in directories. Instead, directories contain links to files (generally hard links, but sometimes symbolic ones). There may be multiple hard links to the same file, in different directories, and one need only reach one of them to potentially access the file. However, the permissions on the file itself affect all access attempts. Dec 7 '21 at 22:04
  • 4
    The OP is unlikely to be dealing with multiple-hard-link situations, but a correct understanding of the true relationship between directories and (other) files is important for other matters, such as "why do I need write permission on the a file's directory to delete it, yet not on the file itself?" Dec 7 '21 at 22:08
  • 1
    @JerzyBrzóska I'm not familiar enough with rust tooling. Could cargo have a shebang? (AFAIK it shouldn't, it should be a native exectuable. Or maybe this is a shell wrapper to the real cargo and it's complaining about running the real cargo?) What does file ~/.cargo/bin/cargo say? What is the complete error message? Dec 7 '21 at 23:17

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.