God misreports permissions when run as a non-root user about god HOT 15 CLOSED

Can you check the parent directories and make sure that they all are executable?

from god.

/var is owned by root, but executable by others:

deploy@li255-140:/var$ ls -la 
total 48
drwxr-xr-x 14 root   root   4096 Apr 27 03:00 .
drwxr-xr-x 21 root   root   4096 May  8 21:27 ..

Everything else up the chain is both owned by deploy and executable.

from god.

Can you run this?

$ ls -ld /var /var/www /var/www/api /var/www/api/shared

from god.

deploy@li255-140:~$ ls -ld /var /var/www /var/www/api /var/www/api/shared
drwxr-xr-x 14 root   root   4096 Apr 27 03:00 /var
drwxr-xr-x  6 deploy deploy 4096 May 20 08:16 /var/www
drwxrwxr-x  4 deploy deploy 4096 May 23 23:00 /var/www/api
drwxrwxr-x  8 deploy deploy 4096 May 23 22:58 /var/www/api/shared

from god.

Can you paste the god recipe you're using? Does it include a chroot directive?

Also, can you paste the output of:

$ ls -l /dev/null

from god.

deploy@li255-140:~$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 May 23 22:17 /dev/null

from god.

Here's the god scripts: https://gist.github.com/987989

from god.

Ah, when running as a non-root user, don't specify w.uid = or w.gid =. That should fix this for you.

Also, there are a couple things you may want to fix:

If you don't specify w.pid_file = for a worker you should specify this somewhere:

God.pid_file_directory = File.join(APP_ROOT, %w(tmp pids))

so god knows where to write the pid files to.

Also, your resque worker shouldn't need to write its own pid file, god will do that automatically if you don't specify a w.pid_file = directive.

The rule is:

• If a w.pid_file = directive is there, expect the w.start = command will spawn a process in the background and write to the file specified in w.pid_file =
• If w.pid_file is not defined, expect the w.start = command will run in the foreground and it will be up to god to run it in the background and to write the pid file based on the w.name in the God.pid_file_directory.

from god.

I just got bitten by this problem as well. The log message is pretty descriptive about the problem, but it also happens to be wrong. Can the log message be changed to reflect the fact that w.uid and w.gid are not permitted when God is not running as root?

Another thing that would help is to mention that the god process's EUID (which is different UID than what is being reported in the log) is the one unable to open the noted files.

from god.

I'd like to second @bklang's suggestion - that would be quite helpful.

from god.

Also just got bitten - would 3rd @bklang's suggestion.

from god.

Yeah, those seem like a good idea.

If someone would be willing to make a pull request with the check and the better error message, I'll definitely review it. I'm not sure how soon I'll have a chance to make the improvement myself, but I'll keep it on my radar.

from god.

First reported in 2011 and still not fixed in 2014?

The error message is so misleading. I'm glad this issue shows up in Google, so I was able to figure out what was happening.

from god.

Happy birthday, misleading error message. At least we're able to find this thread that explains w.uid and w.gid are not permitted when God is not running as root.

from god.

+1

from god.