2

I originally login with $HOME as /home/oleg

I need to run a command with sudo - this happens to be an npm install command-

sudo npm install -g suman

however, 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?

1

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 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 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 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.

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 solutions

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 /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.

  • Thanks, however my experience seems to suggest that root does always not have access to all files in a user's directory, not sure why but that's definitely been the case in a few scenarios. I remember I logged in as root before and had trouble modifying my own .bashrc and .profiles files once. Not sure what to say except for whatever reason root did not have write access at least. – Alexander Mills Feb 21 '17 at 4:20
  • Thanks, Is there any way to determine what the root user's $HOME dir is, if the -H switch is not used? I cannot guarantee that the users of my lib will use the -H flag. – Alexander Mills Feb 21 '17 at 4:25
  • I am writing using fs.writeFile - nodejs.org/api/…, the default mode is 666, I assume that means that root cannot execute the file if it was written to the original user's home – Alexander Mills Feb 21 '17 at 4:52
  • neglected...if I run npm install with sudo, then the postinstall script does not have permissions to create a dir (mkdir) in my original user's directory. I don't know if my machine is somehow misconfigured, but it seems to be an overstatement to say that root has total access; unless I misunderstood what you said. – Alexander Mills Feb 21 '17 at 17:41
  • @AlexanderMills Re. not having access to your dot files as root: read the section “Root already has permission” of my answer. You probably have an encrypted home directory. Re. what to do in your postinstall: if running as root, don't write to $HOME, write under /var. – Gilles Feb 21 '17 at 18:35
1

What you're looking for is is the -H, --set-home parameter to sudo.

From the sudo man page:

-H, --set-home Request that the security policy set the HOME environment variable to the home directory specified by the target user's password database entry. Depending on the policy, this may be the default behavior.

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.