14

I often see users that try to fix an issue and somewhere read or just try to recursively chown their home directory and sometimes even also reset permissions recursively to something like rwxr-xr-x or similar.

Imagine such an owner/permission massacre - are there critical files/directories that need special permissions or to be root-owned for the system to work?

  • 1
    Wat files are you talking about? Why would critical files owned by root be in a user home? – mikewhatever Sep 11 '15 at 12:51
  • 1
    @mikewhatever I know at least three directories that need to be owned by root: ~/.gvfs/, ~/.cache/gvfs-burn/ and ~/.cache/dconf. Probably there are more. – Byte Commander Sep 11 '15 at 13:05
  • 1
    drwx------ 2 romano romano 4096 dic 2 2008 .gvfs and never had any problem.... (see the date). Also drwx------ 2 romano romano 4096 abr 28 14:57 .cache/dconf – Rmano Sep 11 '15 at 13:06
  • 3
    There are no "critical" files in the user's home the directory, if there are then it's the result of a very bad programming, since the user can remove them on purpose / by mistake in a flash. Unless it's a mistake, "critical" files are stored elsewhere. – kos Sep 11 '15 at 13:08
  • FWIW, I can confirm that ~/.gvfs and ~/.cache/dconf on my system are both owned by root. I ran "sudo ls -Al" on both directories, and they're both empty. Although I've changed group and other permissions for documents, I have never ever run chown. So, root ownership for these two directories could well be normal, at least for Ubuntu 15.04. Also, I don't have a ~/.cache/gvfs-burn directory, or the ipc-admin directories mentioned by Byte Commander that are root-owned. But, the numeric-alpha-named file in ~/.dbus/session-bus is owned by Me, not root. – user173876 Sep 16 '15 at 6:41
17

NO file in ~ has to be owned by root.

If a software requires that a file in your home directory be owned by another user, it is a bug and should be reported as such.

Other than that, a common case involves two security-related software that require restricted permissions on certain files, namely:

  1. SSH
  2. GPG

SSH

See man ssh, section FILES:

 ~/.ssh/config
     This is the per-user configuration file.  The file format and
     configuration options are described in ssh_config(5).  Because of
     the potential for abuse, this file must have strict permissions:
     read/write for the user, and not writable by others.  It may be
     group-writable provided that the group in question contains only
     the user.

 ~/.ssh/identity
 ~/.ssh/id_dsa
 ~/.ssh/id_ecdsa
 ~/.ssh/id_ed25519
 ~/.ssh/id_rsa
     Contains the private key for authentication.  These files contain
     sensitive data and should be readable by the user but not acces‐
     sible by others (read/write/execute).  ssh will simply ignore a
     private key file if it is accessible by others.  It is possible
     to specify a passphrase when generating the key which will be
     used to encrypt the sensitive part of this file using 3DES.

Other files like authorized_keys, known_hosts, etc. should be writable only by the user, but can be world-readable.

GnuPG

~/.gnupg (and contents) should be accessible only by you. With other permissions, GPG will complain about unsafe permissions.

  • So what about ~/.gvfs/, ~/.cache/gvfs-burn/ and ~/.cache/dconf? They're root-owned and I think they should be. – Byte Commander Sep 11 '15 at 13:25
  • 2
    @ByteCommander nope. Use sudo with GUI programs, did you? – muru Sep 11 '15 at 13:26
  • Not that I could remember it... I'm creating a new user and checking there. One moment, please. – Byte Commander Sep 11 '15 at 13:27
  • @ByteCommander have a look: bugzilla.gnome.org/show_bug.cgi?id=534284 – muru Sep 11 '15 at 13:35
  • 1
    @ByteCommander if that was the intention, then sudo -i or sudo -H probably should be used. – muru Sep 11 '15 at 14:17
11

In general files and directory in your home should be owned by you.
I have some strange root-owned files that are probably the result of executing sudo command; in fact there are programs that write things under $HOME (which well behaved programs requiring super-user privileges shouldn't do --- the effect is root taking ownership of files that should belongs to the user).
Normally deleting or re-owning them (depending on the file) does not create problems and often it solves some, like the infamous .Xauthority file --- and sometimes, after running sudo dconf-editor, you have things in configurations you can't modify anymore.

About special modes:

  • scripts must be executable, of course, at least to the owner;
  • so must be directories too (where x means right to cross);
  • .ssh must be drwx------ (0700) and the private keys in it -rw------- (0600)
  • if you have a Public directory for sharing, it should be probably drwxr-xr-x (read permission to anyone) or drwxrwxrwt (with write permission and sticky bit, for enabling writing).

... I can't think to anything more needing special treatment.

  • So what about ~/.gvfs/, ~/.cache/gvfs-burn/ and ~/.cache/dconf? They're root-owned and I think they should be. – Byte Commander Sep 11 '15 at 13:25
  • @ByteCommander --- all that things are owned by me in my system, and nothing misfunctions. Why do you think they must be owned by root? In dconf is your configuration, and the privileged command/daemon that does the mounting of partitions should switch ownership to you --- otherwise it's a bug. I commented this on your question. – Rmano Sep 11 '15 at 13:29
  • I've found another two files owned by root that I am not sure whether it's right or wrong: ~/.dbus/session-bus/7ae519bec942595a6925fb2d5448031b-1 and /home/ipc-admin/.aptitude/config, much stuff under /home/ipc-admin/.cache/pip/wheels/, /home/ipc-admin/.local/share/session_migration-(null) and /home/ipc-admin/.local/share/applications/mimeapps.list. Can you imagine why those are root-owned on my system? – Byte Commander Sep 11 '15 at 13:52

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.