0

I noticed that after installing something using sudo I cannot run the application without sudo even though the executable is in my path. I have to go into the application directory and manually change the permissions (using chmod -R o=g <application>/). I have experienced this in 16.04, 14.04, and maybe even in 12.04. Why is this the default behavior and how can I change this?

As an example, I just compiled and installed KeePassX 0.4.4. Using the default installation commands (qmake, make, sudo make install), the executable is /usr/bin/keepassx with the expected permissions, 755, but files this executable points to, in /usr/share/keepassx/ have permissions 750 preventing execution without using sudo.

When I install an application using apt, apt-get, or dpkg -i I use sudo but all users can run the application. How do I mimic this behavior when compiling and installing an application from source? I realize I could add a chmod command to the Makefile but is there a way to make a change once that will propagate to future installs?

1

There are lots of programs that will sill be in your path that won't work for normal users. An example is adduser. So it would depend on the program that you want to run.

I don't know what the KeePassX 0.4.4 program does, but it would be up to the developers of whether to make the program available to normal users or to require the elevated command to run.

As far as compiling, which it appears that you did that correctly, you should build and compile the programs as a normal user. Only run the make install part with the elevated command. This way the program becomes install system-wide.

You shouldn't have go into the system to make any changes. If you change the files you might actually break the application.

Some programs needs to be run as root so that they will have access to certain files that normal users can't access, such as using the command to change your password, which also edits the /etc/passwd and the /etc/shadow files. Program such as those have the suid bit set so that it will run as root even when called by a normal user.

You wouldn't want to change the permissions of your /etc/passwd and /etc/shadow files so that you can edit them as a normal user, or so that the passwd command will work without the suid bit set.

So it would depend on which programs that you are installing and the intent of the program provider.

If the program needs root access, the make install should set the suid bit. If it isn't intended to work as root and intended to work by for a normal user, the program or install is broke and should be addressed to the developer so they could fix it.

You might find notes in the Readme of the program to fix the bugs, which would be in this case, if make install is failing and causing you to have to go in and fix it.

  • Perhaps it is a bug in their Makefile. I would need to test this to be certain but I recall compiling and installing the same application (maybe htop) on both CentOS and Ubuntu systems (they could not access the internet) and could run the application out of the box on CentOS but not Ubuntu. This is why it seems like a system configuration/setting. – Steven C. Howell Sep 8 '16 at 17:52
  • 1
    The Makefile is provided by the program's developer. It's the Makefile that would actually set the suid bit and the userID so that the program would run by the intended user with the intended permissions. If the program doesn't do that, and that's the expected behavior, then, as I mentioned in the answer, it's broken and should be brought to the attention of the developer. By the way, I built and installed the htop from the git site you linked. It works without running it with sudo. – L. D. James Sep 8 '16 at 18:04
  • @stvn66 Is the htop one of the programs that won't run unless you use sudo htop? Also, to build it I had to install the libncursesw5-dev with apt-get. Other than that the one liner install instructions from the Readme worked perfect. If it doesn't work perfect for you, we can investigate why. – L. D. James Sep 8 '16 at 18:08
  • I am not sure which program it was that ran on CentOS but not Ubuntu (it may have been emacs) but your response seems reasonable. It is good to know this unexpected behavior is not a setting I can change but oversight of developers (probably not the most important bug they face). – Steven C. Howell Sep 8 '16 at 20:28
0

This is because when you run via sudo you are root not your normal user.

Attempts to write config files or setup user versions of libraries will go to /root instead of /home/your_user.

when you run without sudo your programs won't find those files.

You could test this by running your program via strace to see what files it tries to load

strace -e open yourprogram
  • When I install an application using apt, apt-get, or dpkg -i I use sudo but all users can run the application. How do I mimic this behavior when compiling and installing an application from source? I realize I could add a chmod command to the Makefile but is there a way to make a change once that will propagate to future installs? – Steven C. Howell Sep 8 '16 at 17:39

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.