1

A regular user can run this script, but root can't find it.

I have a simple script that I have saved in ~/bin. I updated the .profile file to include this folder in the PATH. I can go into terminal, be working in any directory, type the name of the script and it runs fine. But if in that terminal I switch to root, the script cannot be found. I assume there is some file somewhere which needs a new $PATH update, but I don't know which one.

6

If you're using sudo, which is probably the case, there is a security policy that modifies the $PATH environment variable to a secure path (defined in the file /etc/sudoers). The ~/bin directory isn't included in the default secure_path set in the sudoers file, so running sudo script wouldn't work, but sudo ~/bin/script would.

You can place the script in one of the folders defined in the sudoers configuration file (i.e. /usr/local/bin) to make it directly accessable. The secure_path can also be changed on the configuration file, though it's not recommended.

  • 1
    Thank you very much for the first answer not recommending to bypass SECURE_PATH. Indeed, either placing the script into a location included in the SECURE_PATH (owned and only writeable by root of course) or, if absolutely necessary and you know what you're doing, specifying the full path is the right and secure way to go. – Byte Commander Sep 30 '16 at 23:21
2

To temporarily prevent sudo from resetting your path to secure_path, for a single command, without modifying any global configuration, you can do:

sudo env PATH=$PATH command

Where command is the name of the executable you want to run that is in your PATH.

You could make an alias for this and add to your own (not root's) ~/.bashrc... something like

alias sudo2='sudo env PATH=$PATH'

Then you could use sudo2 command to run an executable file with sudo using your own PATH.

  • 1
    +1 for the alias solution! Simple way to solve the issue without having to touch the default sudoers config – IanC Sep 30 '16 at 22:49
  • @ByteCommander I try to operate without using sudo. This includes, so that my personal space don't get changed away from my normal login access. I only use sudo when I want to make system changes. So I don't want to operate as root. However, if my account were compromised, my system would be at the mercy of whoever compromised it. I won't remove my account form sudoer. I take measures to not have my account compromised. I won't fool myself into thinking a person can have access to my account and not also have root access. I don't share my account or my passwords with anybody. – L. D. James Oct 1 '16 at 0:00
0

Why the script fails when run by root?

You have to check the path of the effective user... in this case root.

Run this:

(The first two lines are the prompts plus the commands. The last line is the output of the command.)

$ sudo su -
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

Recommendations for where to place your script to be run by others:

Make a subdirectory under /opt for your project and place your project's exec scripts there. This is a place that will survive an OS fresh install on the same partition (minus formatting of course).

The root area for your scripts can be in:

/opt/myprojectname/myscriptfiles/

Now you can link your scripts /usr/local/bin/ with

$ sudo ln -s /opt/myprojectname/myscriptfile/myscript.sh /usr/local/bin/myscript.sh`

You won't have to change the the root $PATH variable, because as you can see from the test above, it's already there.

So rather than changing the root path, you can change your path to search the /opt/myprojectname/myscriptname

Alternatively, you could link your ~/bin/myscript.sh to /usr/local/bin/myscript.sh.

  • Thanks. I was hoping for a more permanent solution so that the scripts I write can still be accessed even when i have to be doing things as root. I have been using your suggested export command, but it becomes tiresome to do it each time I open a terminal. I guess I expected that, as can be done for the local user, the root user would have a file to which the directory could be added. – dhp904 Sep 30 '16 at 22:59
  • @dhp904 Use the last alternative... the sudo ln -s ~/bin/myscript.sh /usr/local/bin/myscript.sh. That will make it available to both you and to root. – L. D. James Sep 30 '16 at 23:01
  • Sorry, but I see a huge security risk there! You add a location to root's $PATH where a normal unprivileged user has full write access. This allows the user (or any malware/hacker that managed to get this access level) to place their own executables there or modify existing ones, waiting for them to get executed as root accidentally. There is a reason why sudo always resets the $PATH variable even when preserving the rest of the environment. I must recommend to avoid bypassing this. – Byte Commander Sep 30 '16 at 23:17
  • Your alternative 2 is not better, it should be the other way round (original file in /usr/local/bin, owned by root and no write permission for others and a symlink to that file in ~/bin - although that would not be necessary for anything). Otherwise you again have the problem of an executable that is owned/writeable by a normal user but likely to get executed with root privileges. – Byte Commander Sep 30 '16 at 23:19
  • @ByteCommander I would expect the file is owned by the author and only writable by author. It appears like he's working on the script and need quick access to check his changes. With the alternative 2 he's not setting a root path. He's setting a root file that he along can make changes to. If another user can write to the file, the would be able to write to it even in the /usr/local/bin which is accessible by root. I would recommend his local files and local installed programs be in a directory that won't be clobbered during a new OS install. – L. D. James Sep 30 '16 at 23:25
0

As others have said, the priviledged environment is not the same as that of the user, and for good reasons. There are mainly two solutions: (i) call your scripts with their path, or (ii) chown your scripts to root and move them higher in the file hierarchy (say, /usr/custom/bin but whatever works), then update the user's PATH, rather than trying to do the contrary.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.