2

I wrote a python script to launch several java applications. I want their PIDs to be filed into /var/run/coma. Therefore I wrote the script and gave it 777 permissions just for testing first.

-rwxrwxrwx  1 root   root    3575 Feb 12 18:20 coma-startup.py

When I launch this script as another user and it executes code to create a file into the mentioned dir I receive the following

PermissionError: [Errno 13] Permission denied: '/var/run/coma/coma-system.pid'

I don't understand this? The script should execute with root privileges in my opinion. What do I not understand here?

xetra11
  • 546
  • No, programs do not normally run as the user that owns the file. That only happens when you set the suid bit, and that only works on binary programs, not scripts. – psusi Feb 12 '18 at 21:23

2 Answers2

4

The permission issue isn't related to the script but to a file acted on by it :

/var/run/coma/coma-system.pid

Try chmod 777 /var/run/coma/coma-system.pid

GAD3R
  • 66,769
Philip Kirkbride
  • 10,236
  • Hm okay I understand what you mean. But what is the best way to let my script be able to create folders and files within /var/run/ ? Can you give an example? – xetra11 Feb 12 '18 at 18:45
  • 1
    Why not run the script with sudo? That way you will have access to any of the files it is attempting to edit. There also might be security issues with setting those files to 777 like I suggest. So go with sudo if that works for you. – Philip Kirkbride Feb 12 '18 at 19:51
  • 1
    Alright will do - seems to be a reasonable approach – xetra11 Feb 12 '18 at 19:53
  • 3
    There are likely to be even more security issues from running the script with sudo. In general, scripts run by sudo should be short, simple, and easily audited. They should do the bare minimum that actually needs root access (and be called by larger, more complex programs as necessary...but they should not trust whatever input or args they are provided, they must validate any data before using it). They should never be editable by non-root users who run them. It would be better & safer to change perms on the file or dir (/var/run/coma/). or use a different directory. – cas Feb 13 '18 at 01:03
  • 1
    sudo is not intended to be a magical fix for permissions problems. It's intended to provide a way for trusted or semi-trusted non-root users to do some specific & limited things as root (or other user). – cas Feb 13 '18 at 01:05
3

Setting the owner and group of a script to root doesn't mean it will be ran as root. When user joe runs an executable, the UID used to define the execution context permissions is the UID of joe, unless you have the set UID (suid) bit enabled. Executables that have suid enabled will run with the UID of the file owner.

However, I think your approach has to be very carefully thought, since suid root executables are a security risk. A malicious user can try to escalate priviledges by exploiting them. If that's the only file you need to handle you should work on its permissions instead, or require the user to use sudo. suid root executables should be a last resort on very specific cases.

Note: As @psusi remarked on the comments, suid won't work on scripts. This answer describes the issue with suid scripts very well, and why they don't work from kernel 3.x on. So for your particular situation you have only the options of changing permissions on the files/folders you need to work on, or using sudo (first option is more advised).

IanC
  • 850