TL,DR: none of your suggestions are good. Instead, when running as root, store state files under
/var (something like
Root already has permission
Root has the permission to access all files in the system. So don't change the directory's permissions: it wouldn't make any difference to root, but it would allow everyone else to read and write in that directory. Despite popular belief, it's extremely rare for
chmod 777 to do anything useful.
Root has the permission to access all files in the system, and normally that's enough. There are a few exceptions that have to do with certain filesystem types that handle users differently from “normal” filesystems. The two main cases are:
- NFS: root on a client is typically mapped to a different user on the server, usually
nobody. This means that when root opens a file, it's done with the permissions of
- FUSE (which includes ecryptfs, which is commonly used to encrypt home directories): unless configured otherwise (with the option
allow_other, which only root can use), FUSE filesystems are only available to the user who mounted them.
In those cases, there are files that root can't access directly despite having apparent permission. Root can still effectively access the files by switching to the account that owns the files — these are implementation limitations, not security restrictions — but it's a little inconvenient.
But root should use that permission carefully
If you have a program that's commonly invoked as root but with
HOME set to another user's home directory, you should try to avoid creating files in a user's home directory that the user can't access.
/home/oleg/.suman already exists and is owned by oleg, it doesn't matter if you write files there, because the owner of a directory can always erase files in that directory (what it takes is write permission, and the owner can always grant themselves permission). When oleg runs the same program, it'll replace the root-owned files if those files need to be overwritten. Don't create subdirectories, however: oleg would be unable to access them or remove them even if they're empty.
The problem is if you run the program for the first time as root and it creates
/home/oleg/.suman. In a nutshell, don't do that — the question is how to avoid it.
If you run
sudo -H then the
HOME environment variable is set to root's home directory and so the program won't be accessing
But sometimes it makes sense to run a program as root (because it needs root permissions) but with the home directory set to your own (to read your configuration files). This of course only applies in cases where it's ok for a program running as root to read that configuration file — user interface customizations are fine, but the configuration file shouldn't contain things like executable code (e.g. no shell escapes through preprocessing). If that's the case, the program should read files from
$HOME but not write.
If the program needs to store some state files, then when it's running as root, it should store them in a system directory (under
/var), not in the user's home directory.