为什么我必须从守护进程中对命令执行sudo命令？

Question

I have a problem about sudo .

I call an Erlang script from a daemon process . (This daemon process is defined by xinetd, and this process will execute an bash script in it. I wrote my Erlang script command into the bash script). The Erlang script is like:

#! /usr/bin/env escript
main(_) ->
    ok.

The script is quite simple and it is ok when I execute it under the shell command line.

But when I call it from the daemon process , it failed with return code of non-zero. I really have no idea.

When I try sudo /path/to/my/erlang_script , it turns alright!!

I am the root myself. Why I have to add sudo ?

My xinetd conf is like: (as you can see 'user' is setup to be 'root')

service gtpgwagent
{
        type            = UNLISTED
        flags           = REUSE
        disable         = no
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        instances       = UNLIMITED
        server          = /lab/subsysserv/sbin/in.gtpgwagent
        server_args     = gtpgw
        log_type        = FILE /tmp/ggsnagent_logfile
        log_on_success  += DURATION USERID HOST EXIT
        log_on_failure  += USERID HOST
        env             = /usr/bin:/bin
        port            = 1761
}

Answer 1

The daemon process is neither running as root nor as a user that has permission to run that script (or, the most common case, is not allowed to do something that script does), so things don't work out.

You are running as root, so whatever you try always works (which is sort of scary, so be careful).

Change permissions on the script to accommodate whatever xinetd is setting the daemon process user to be, and make sure whatever you have the script do is something the daemon process user is allowed to do. Whatever you do, though, do not set a daemon to run as root -- that is just an accident (or crack) waiting to happen.

Edit

RHEL 6.x is almost guaranteed to prevent daemons running as root from doing almost anything .

• Try turning SELinux off and see if that changes the outcome (do setenforce 0 , then run your test, then do setenforce 1 to turn it back on).
• Set the user to something different (create a system user for this purpose if you need: useradd -r [blahblah] ).
• Check how role-based permissions work ( http://www.ibm.com/developerworks/library/l-rbac-selinux/ ).
• Look for threads related to this issue somewhere like unix.se or serverfault.se or a RHEL/SL/CentOS IRC channel or forum -- you're almost certainly not the only one who has run into this.
• Whatever you do don't disable SELinux because of this ! Seriously, don't . As a developer or a sysop or as devops you should learn how it works -- it is a very important tool. Don't stoop to the pixels-first mindset.