I originally login with $HOME as /home/olegI need to run a command with sudo - this happens to be an npm install command-sudo npm install -g sumanhowever, the postinstall script for the suman module, as it's currently configured, writes to the original user's home directory /home/oleg/.suman....but because I run the above npm install command with sudo, I do not have access to /home/oleg/.suman. Is there any hope to give the root user access to the /home/oleg/.suman directory?Or should the postinstall script for suman simply install to the root user's home directory?It looks like, since I wrote suman :), that I can write the contents of the .suman directory with 777 and given full access to the root user in this way. I guess what are the minimum file permissions to define for the .suman directory to give read/write/execute access to only the root user and the logged in user?
Using sudo to write files to user's home
files;permissions;home
TL,DR: none of your suggestions are good. Instead, when running as root, store state files under /var (something like /var/lib/suman).Root already has permissionRoot 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 nobody.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 carefullyIf 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.If /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.The solutionsIf you run sudo -H then the HOME environment variable is set to root's home directory and so the program won't be accessing /home/oleg.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.