16

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?

Byte Commander
  • 107,489
  • 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. –  Sep 16 '15 at 06:41
  • Oh, ipc-admin was the username. So /home/ipc-admin/ is the same as ~/... – Byte Commander Sep 16 '15 at 07:59
  • Is this a default setup? Fresh installation? Never run sudo with any command that could touch your home directory? If not, this answer is a comment, at best. – muru Sep 18 '15 at 03:30
  • For .rpmdb owned by root in your home read this answer. Summary: It's a bug and probably caused by DKMS trying to run RPM commands. – LiveWireBT Sep 21 '15 at 08:53

2 Answers2

19

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.

muru
  • 197,895
  • 55
  • 485
  • 740
  • 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: https://bugzilla.gnome.org/show_bug.cgi?id=534284 – muru Sep 11 '15 at 13:35
  • The new user has indeed no root-owned files, but it does not have that .gvfs-directory at all yet. Hmm... So that means I was wrong there and chown -R-ing one's home directory is no problem at all? I swear I've read somewhere that a bunch of directories/files needs to be root-owned, especially those gvfs-related things. – Byte Commander Sep 11 '15 at 13:45
  • 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:53
  • @ByteCommander presumably you used sudo with aptitude, pip, etc. and made some changes to configuration or something, and sudo didn't reset $HOME. – muru Sep 11 '15 at 14:03
  • And how should I have used aptitude or pip properly without sudo? Do I need sudo -H or anything like that for those in future or what? – Byte Commander Sep 11 '15 at 14:11
  • @ByteCommander depends on what you did. With pip, do pip --user without sudo. – muru Sep 11 '15 at 14:12
  • But pip --user does not install python packages system-wide, which was intended. – Byte Commander Sep 11 '15 at 14:13
  • 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.

Rmano
  • 31,947
  • 1
    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
  • 1
    @ByteCommander Because the process creating them is running as root. (sorry for the 8-year delay in replying - you may know this by now :) ) – jtlz2 May 18 '23 at 10:28