FAQ
Hello!

I was just wondering whether it's possible to run salt-api as unprivileged
user.
I have salt-master running as unprivileged user, and salt-api on the same
host
(they share configuration files so it's probably not a misconfiguration on
my side)

I checked the docs
<http://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_cherrypy.html> and
they don't indicate that there's 'user' or similar option.

FYI I am running latest stable packages (Helium) versions on Ubuntu 14.04.1

I could probably hack init script however I doubt it's optimal to do so ;)

Did I miss something or there isn't currently way to instruct salt-api to
use another uid ?



--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Stephen Spencer at Jan 27, 2015 at 10:58 pm
    I'm pretty sure you have to run salt-api as the same user as the
    salt-master due to it needing access to the salt-master sockets.
      (/var/run/salt/master/*.ipc). If you're concerned about exposing
    root-owned procs, I'd suggest converting your salt-master to running as a
    non-root user then neither component will live in that realm.

    -S


    On Tue, Jan 27, 2015 at 9:16 AM, Sławomir Kowalski wrote:

    Hello!

    I was just wondering whether it's possible to run salt-api as unprivileged
    user.
    I have salt-master running as unprivileged user, and salt-api on the same
    host
    (they share configuration files so it's probably not a misconfiguration on
    my side)

    I checked the docs
    <http://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_cherrypy.html> and
    they don't indicate that there's 'user' or similar option.

    FYI I am running latest stable packages (Helium) versions on Ubuntu 14.04.1

    I could probably hack init script however I doubt it's optimal to do so ;)

    Did I miss something or there isn't currently way to instruct salt-api to
    use another uid ?



    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the terrible
    things that happen to us come because we actually deserve them? So, now I
    take great comfort in the general hostility and unfairness of the universe.

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sławomir Kowalski at Jan 28, 2015 at 7:25 am
    Hello Stephen.

    Here's the problem:
    my salt-master *already* runs as non-root user.
    And salt-api runs as root. I think salt-api running as root will still have
    access to IPC sockets because they're just files and root user
    is not subject to file access permission so salt-api won't ever be denied
    access to those files.

    That's why I asked here - I'm not sure whether its a bug or salt-api needs
    to use root permissions. However as I use port >1024
    for rest_cherrypy module I don't see any reason to have salt-api running as
    superuser .


    Here's output from `sudo salt-api -l debug`:

    [DEBUG ] Reading configuration from /etc/salt/master
    [DEBUG ] Including configuration from '/etc/salt/master.d/api.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/api.conf
    [DEBUG ] Including configuration from '/etc/salt/master.d/reactor.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/reactor.conf
    [DEBUG ] Using cached minion ID from /etc/salt/minion_id: <redacted>
    [DEBUG ] Configuration file path: /etc/salt/master
    [DEBUG ] Created pidfile: /var/run/salt-api.pid
    *[DEBUG ] Chowned pidfile: /var/run/salt-api.pid to user: salt*
    [ERROR ] Not loading 'rest_wsgi'. 'port' not specified in config
    [INFO ] Starting 'rest.start' api module
    [DEBUG ] SaltEvent PUB socket URI:
    ipc:///var/run/salt/master/master_event_pub.ipc
    [DEBUG ] SaltEvent PULL socket URI:
    ipc:///var/run/salt/master/master_event_pull.ipc
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGHUP.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGTERM.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGUSR1.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Bus STARTING
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Started monitor thread
    '_TimeoutMonitor'.

    For me it looks like it does usual stuff like chowning pids but actually
    never switches to target user.



    W dniu wtorek, 27 stycznia 2015 16:16:43 UTC+1 użytkownik Sławomir Kowalski
    napisał:
    Hello!

    I was just wondering whether it's possible to run salt-api as unprivileged
    user.
    I have salt-master running as unprivileged user, and salt-api on the same
    host
    (they share configuration files so it's probably not a misconfiguration on
    my side)

    I checked the docs
    <http://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_cherrypy.html> and
    they don't indicate that there's 'user' or similar option.

    FYI I am running latest stable packages (Helium) versions on Ubuntu 14.04.1

    I could probably hack init script however I doubt it's optimal to do so ;)

    Did I miss something or there isn't currently way to instruct salt-api to
    use another uid ?


    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stephen Spencer at Jan 31, 2015 at 6:19 pm
    Interesting. So the salt-api.pid indicates it is aware of the salt user.
    Does it show up as owned by *root* in the process table?

    -S
    On Wed, Jan 28, 2015 at 1:25 AM, Sławomir Kowalski wrote:

    Hello Stephen.

    Here's the problem:
    my salt-master *already* runs as non-root user.
    And salt-api runs as root. I think salt-api running as root will still
    have access to IPC sockets because they're just files and root user
    is not subject to file access permission so salt-api won't ever be denied
    access to those files.

    That's why I asked here - I'm not sure whether its a bug or salt-api
    needs to use root permissions. However as I use port >1024
    for rest_cherrypy module I don't see any reason to have salt-api running
    as superuser .


    Here's output from `sudo salt-api -l debug`:

    [DEBUG ] Reading configuration from /etc/salt/master
    [DEBUG ] Including configuration from '/etc/salt/master.d/api.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/api.conf
    [DEBUG ] Including configuration from '/etc/salt/master.d/reactor.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/reactor.conf
    [DEBUG ] Using cached minion ID from /etc/salt/minion_id: <redacted>
    [DEBUG ] Configuration file path: /etc/salt/master
    [DEBUG ] Created pidfile: /var/run/salt-api.pid
    *[DEBUG ] Chowned pidfile: /var/run/salt-api.pid to user: salt*
    [ERROR ] Not loading 'rest_wsgi'. 'port' not specified in config
    [INFO ] Starting 'rest.start' api module
    [DEBUG ] SaltEvent PUB socket URI:
    ipc:///var/run/salt/master/master_event_pub.ipc
    [DEBUG ] SaltEvent PULL socket URI:
    ipc:///var/run/salt/master/master_event_pull.ipc
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGHUP.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGTERM.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGUSR1.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Bus STARTING
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Started monitor thread
    '_TimeoutMonitor'.

    For me it looks like it does usual stuff like chowning pids but actually
    never switches to target user.



    W dniu wtorek, 27 stycznia 2015 16:16:43 UTC+1 użytkownik Sławomir
    Kowalski napisał:
    Hello!

    I was just wondering whether it's possible to run salt-api as
    unprivileged user.
    I have salt-master running as unprivileged user, and salt-api on the same
    host
    (they share configuration files so it's probably not a misconfiguration
    on my side)

    I checked the docs
    <http://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_cherrypy.html> and
    they don't indicate that there's 'user' or similar option.

    FYI I am running latest stable packages (Helium) versions on Ubuntu
    14.04.1

    I could probably hack init script however I doubt it's optimal to do so
    ;)

    Did I miss something or there isn't currently way to instruct salt-api to
    use another uid ?



    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the terrible
    things that happen to us come because we actually deserve them? So, now I
    take great comfort in the general hostility and unfairness of the universe.

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sławomir Kowalski at Jan 31, 2015 at 7:46 pm
    Yes it does,

    here's output from `ps -C 'python /usr/bin/salt-api' -C 'salt-master' -o
    pid,ppid,tty,session,uid,user,command`:

       PID PPID TT SESS UID USER COMMAND
      1189 7635 ? 7576 999 salt [salt-master] <defunct>
      7576 1 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7580 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7581 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7582 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7635 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7636 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7639 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7640 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7641 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7642 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7643 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7644 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7645 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7646 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7651 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7652 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7661 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7662 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7663 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7664 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7667 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7669 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7670 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7676 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7678 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7689 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7691 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7695 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7696 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7699 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7700 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7719 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7727 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7728 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7731 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7732 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7741 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7745 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
      7753 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    *16961 1 ? 16961 0 root python /usr/bin/salt-api*
    *16966 16961 ? 16961 0 root python /usr/bin/salt-api*


    W dniu sobota, 31 stycznia 2015 19:19:02 UTC+1 użytkownik Stephen Spencer
    napisał:
    Interesting. So the salt-api.pid indicates it is aware of the salt user.
    Does it show up as owned by *root* in the process table?

    -S

    On Wed, Jan 28, 2015 at 1:25 AM, Sławomir Kowalski <sua...@gmail.com
    <javascript:>> wrote:
    Hello Stephen.

    Here's the problem:
    my salt-master *already* runs as non-root user.
    And salt-api runs as root. I think salt-api running as root will still
    have access to IPC sockets because they're just files and root user
    is not subject to file access permission so salt-api won't ever be denied
    access to those files.

    That's why I asked here - I'm not sure whether its a bug or salt-api
    needs to use root permissions. However as I use port >1024
    for rest_cherrypy module I don't see any reason to have salt-api running
    as superuser .


    Here's output from `sudo salt-api -l debug`:

    [DEBUG ] Reading configuration from /etc/salt/master
    [DEBUG ] Including configuration from '/etc/salt/master.d/api.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/api.conf
    [DEBUG ] Including configuration from '/etc/salt/master.d/reactor.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/reactor.conf
    [DEBUG ] Using cached minion ID from /etc/salt/minion_id: <redacted>
    [DEBUG ] Configuration file path: /etc/salt/master
    [DEBUG ] Created pidfile: /var/run/salt-api.pid
    *[DEBUG ] Chowned pidfile: /var/run/salt-api.pid to user: salt*
    [ERROR ] Not loading 'rest_wsgi'. 'port' not specified in config
    [INFO ] Starting 'rest.start' api module
    [DEBUG ] SaltEvent PUB socket URI:
    ipc:///var/run/salt/master/master_event_pub.ipc
    [DEBUG ] SaltEvent PULL socket URI:
    ipc:///var/run/salt/master/master_event_pull.ipc
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGHUP.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGTERM.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGUSR1.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Bus STARTING
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Started monitor thread
    '_TimeoutMonitor'.

    For me it looks like it does usual stuff like chowning pids but actually
    never switches to target user.



    W dniu wtorek, 27 stycznia 2015 16:16:43 UTC+1 użytkownik Sławomir
    Kowalski napisał:
    Hello!

    I was just wondering whether it's possible to run salt-api as
    unprivileged user.
    I have salt-master running as unprivileged user, and salt-api on the
    same host
    (they share configuration files so it's probably not a misconfiguration
    on my side)

    I checked the docs
    <http://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_cherrypy.html> and
    they don't indicate that there's 'user' or similar option.

    FYI I am running latest stable packages (Helium) versions on Ubuntu
    14.04.1

    I could probably hack init script however I doubt it's optimal to do so
    ;)

    Did I miss something or there isn't currently way to instruct salt-api
    to use another uid ?



    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.


    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the terrible
    things that happen to us come because we actually deserve them? So, now I
    take great comfort in the general hostility and unfairness of the universe.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Seth House at Jan 31, 2015 at 8:22 pm
    It is possible to run salt-api as non-root. In fact it's possible to
    run salt-api as a different user than the salt-master (the eauth
    system handles most of that).

    If you start it directly as the same user the salt-master is running
    as it will Just Work (TM). But there is no `saltapi_user` setting to
    drop privs after, say, an init script starts it as root.

    Will you please file a feature enhancement on GitHub? We'll get that
    added. In the meantime, you could work around the problem by editing
    the init script to start it as a specific user using `su`.
    On Sat, Jan 31, 2015 at 12:46 PM, Sławomir Kowalski wrote:
    Yes it does,

    here's output from `ps -C 'python /usr/bin/salt-api' -C 'salt-master' -o
    pid,ppid,tty,session,uid,user,command`:

    PID PPID TT SESS UID USER COMMAND
    1189 7635 ? 7576 999 salt [salt-master] <defunct>
    7576 1 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7580 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7581 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7582 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7635 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7636 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7639 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7640 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7641 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7642 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7643 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7644 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7645 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7646 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7651 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7652 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7661 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7662 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7663 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7664 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7667 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7669 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7670 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7676 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7678 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7689 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7691 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7695 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7696 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7699 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7700 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7719 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7727 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7728 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7731 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7732 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7741 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7745 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7753 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    16961 1 ? 16961 0 root python /usr/bin/salt-api
    16966 16961 ? 16961 0 root python /usr/bin/salt-api


    W dniu sobota, 31 stycznia 2015 19:19:02 UTC+1 użytkownik Stephen Spencer
    napisał:
    Interesting. So the salt-api.pid indicates it is aware of the salt user.
    Does it show up as owned by root in the process table?

    -S

    On Wed, Jan 28, 2015 at 1:25 AM, Sławomir Kowalski <sua...@gmail.com>
    wrote:
    Hello Stephen.

    Here's the problem:
    my salt-master already runs as non-root user.
    And salt-api runs as root. I think salt-api running as root will still
    have access to IPC sockets because they're just files and root user
    is not subject to file access permission so salt-api won't ever be denied
    access to those files.

    That's why I asked here - I'm not sure whether its a bug or salt-api
    needs to use root permissions. However as I use port >1024
    for rest_cherrypy module I don't see any reason to have salt-api running
    as superuser .


    Here's output from `sudo salt-api -l debug`:

    [DEBUG ] Reading configuration from /etc/salt/master
    [DEBUG ] Including configuration from '/etc/salt/master.d/api.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/api.conf
    [DEBUG ] Including configuration from '/etc/salt/master.d/reactor.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/reactor.conf
    [DEBUG ] Using cached minion ID from /etc/salt/minion_id: <redacted>
    [DEBUG ] Configuration file path: /etc/salt/master
    [DEBUG ] Created pidfile: /var/run/salt-api.pid
    [DEBUG ] Chowned pidfile: /var/run/salt-api.pid to user: salt
    [ERROR ] Not loading 'rest_wsgi'. 'port' not specified in config
    [INFO ] Starting 'rest.start' api module
    [DEBUG ] SaltEvent PUB socket URI:
    ipc:///var/run/salt/master/master_event_pub.ipc
    [DEBUG ] SaltEvent PULL socket URI:
    ipc:///var/run/salt/master/master_event_pull.ipc
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGHUP.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGTERM.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGUSR1.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Bus STARTING
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Started monitor thread
    '_TimeoutMonitor'.

    For me it looks like it does usual stuff like chowning pids but actually
    never switches to target user.



    W dniu wtorek, 27 stycznia 2015 16:16:43 UTC+1 użytkownik Sławomir
    Kowalski napisał:
    Hello!

    I was just wondering whether it's possible to run salt-api as
    unprivileged user.
    I have salt-master running as unprivileged user, and salt-api on the
    same host
    (they share configuration files so it's probably not a misconfiguration
    on my side)

    I checked the docs and they don't indicate that there's 'user' or
    similar option.

    FYI I am running latest stable packages (Helium) versions on Ubuntu
    14.04.1

    I could probably hack init script however I doubt it's optimal to do so
    ;)

    Did I miss something or there isn't currently way to instruct salt-api
    to use another uid ?

    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the terrible
    things that happen to us come because we actually deserve them? So, now I
    take great comfort in the general hostility and unfairness of the universe.
    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sławomir Kowalski at Jan 31, 2015 at 8:37 pm
    Hello, Seth!

    I created issue <https://github.com/saltstack/salt/issues/20280> on github
    as you suggested.
    Thanks for possible workaround.
    I was also thinking of running salt-api from monit - it adds nice feature
    of restarting
    it if it fails for any reason.


    W dniu sobota, 31 stycznia 2015 21:22:08 UTC+1 użytkownik Seth House
    napisał:
    It is possible to run salt-api as non-root. In fact it's possible to
    run salt-api as a different user than the salt-master (the eauth
    system handles most of that).

    If you start it directly as the same user the salt-master is running
    as it will Just Work (TM). But there is no `saltapi_user` setting to
    drop privs after, say, an init script starts it as root.

    Will you please file a feature enhancement on GitHub? We'll get that
    added. In the meantime, you could work around the problem by editing
    the init script to start it as a specific user using `su`.

    On Sat, Jan 31, 2015 at 12:46 PM, Sławomir Kowalski <sua...@gmail.com
    <javascript:>> wrote:
    Yes it does,

    here's output from `ps -C 'python /usr/bin/salt-api' -C 'salt-master' -o
    pid,ppid,tty,session,uid,user,command`:

    PID PPID TT SESS UID USER COMMAND
    1189 7635 ? 7576 999 salt [salt-master] <defunct>
    7576 1 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7580 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7581 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7582 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7635 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7636 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7639 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7640 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7641 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7642 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7643 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7644 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7645 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7646 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7651 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7652 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7661 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7662 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7663 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7664 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7667 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7669 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7670 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7676 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7678 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7689 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7691 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7695 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7696 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7699 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7700 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7719 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7727 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7728 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7731 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7732 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7741 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7745 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7753 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    16961 1 ? 16961 0 root python /usr/bin/salt-api
    16966 16961 ? 16961 0 root python /usr/bin/salt-api


    W dniu sobota, 31 stycznia 2015 19:19:02 UTC+1 użytkownik Stephen Spencer
    napisał:
    Interesting. So the salt-api.pid indicates it is aware of the salt
    user.
    Does it show up as owned by root in the process table?

    -S

    On Wed, Jan 28, 2015 at 1:25 AM, Sławomir Kowalski <sua...@gmail.com>
    wrote:
    Hello Stephen.

    Here's the problem:
    my salt-master already runs as non-root user.
    And salt-api runs as root. I think salt-api running as root will still
    have access to IPC sockets because they're just files and root user
    is not subject to file access permission so salt-api won't ever be
    denied
    access to those files.

    That's why I asked here - I'm not sure whether its a bug or salt-api
    needs to use root permissions. However as I use port >1024
    for rest_cherrypy module I don't see any reason to have salt-api
    running
    as superuser .


    Here's output from `sudo salt-api -l debug`:

    [DEBUG ] Reading configuration from /etc/salt/master
    [DEBUG ] Including configuration from '/etc/salt/master.d/api.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/api.conf
    [DEBUG ] Including configuration from
    '/etc/salt/master.d/reactor.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/reactor.conf
    [DEBUG ] Using cached minion ID from /etc/salt/minion_id: <redacted>
    [DEBUG ] Configuration file path: /etc/salt/master
    [DEBUG ] Created pidfile: /var/run/salt-api.pid
    [DEBUG ] Chowned pidfile: /var/run/salt-api.pid to user: salt
    [ERROR ] Not loading 'rest_wsgi'. 'port' not specified in config
    [INFO ] Starting 'rest.start' api module
    [DEBUG ] SaltEvent PUB socket URI:
    ipc:///var/run/salt/master/master_event_pub.ipc
    [DEBUG ] SaltEvent PULL socket URI:
    ipc:///var/run/salt/master/master_event_pull.ipc
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGHUP.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGTERM.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGUSR1.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Bus STARTING
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Started monitor thread
    '_TimeoutMonitor'.

    For me it looks like it does usual stuff like chowning pids but
    actually
    never switches to target user.



    W dniu wtorek, 27 stycznia 2015 16:16:43 UTC+1 użytkownik Sławomir
    Kowalski napisał:
    Hello!

    I was just wondering whether it's possible to run salt-api as
    unprivileged user.
    I have salt-master running as unprivileged user, and salt-api on the
    same host
    (they share configuration files so it's probably not a
    misconfiguration
    on my side)

    I checked the docs and they don't indicate that there's 'user' or
    similar option.

    FYI I am running latest stable packages (Helium) versions on Ubuntu
    14.04.1

    I could probably hack init script however I doubt it's optimal to do
    so
    ;)

    Did I miss something or there isn't currently way to instruct
    salt-api
    to use another uid ?

    --
    You received this message because you are subscribed to the Google
    Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an
    email to salt-users+...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the
    terrible
    things that happen to us come because we actually deserve them? So, now
    I
    take great comfort in the general hostility and unfairness of the
    universe.
    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Vye at Jan 31, 2015 at 9:17 pm
    Supervisor works well too.

    http://supervisord.org/

    --Vye
    Sent from my iPhone
    On Jan 31, 2015, at 12:37 PM, Sławomir Kowalski wrote:

    Hello, Seth!

    I created issue on github as you suggested.
    Thanks for possible workaround.
    I was also thinking of running salt-api from monit - it adds nice feature of restarting
    it if it fails for any reason.


    W dniu sobota, 31 stycznia 2015 21:22:08 UTC+1 użytkownik Seth House napisał:
    It is possible to run salt-api as non-root. In fact it's possible to
    run salt-api as a different user than the salt-master (the eauth
    system handles most of that).

    If you start it directly as the same user the salt-master is running
    as it will Just Work (TM). But there is no `saltapi_user` setting to
    drop privs after, say, an init script starts it as root.

    Will you please file a feature enhancement on GitHub? We'll get that
    added. In the meantime, you could work around the problem by editing
    the init script to start it as a specific user using `su`.
    On Sat, Jan 31, 2015 at 12:46 PM, Sławomir Kowalski wrote:
    Yes it does,

    here's output from `ps -C 'python /usr/bin/salt-api' -C 'salt-master' -o
    pid,ppid,tty,session,uid,user,command`:

    PID PPID TT SESS UID USER COMMAND
    1189 7635 ? 7576 999 salt [salt-master] <defunct>
    7576 1 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7580 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7581 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7582 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7635 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7636 7576 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7639 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7640 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7641 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7642 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7643 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7644 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7645 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7646 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7651 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7652 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7661 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7662 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7663 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7664 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7667 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7669 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7670 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7676 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7678 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7689 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7691 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7695 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7696 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7699 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7700 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7719 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7727 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7728 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7731 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7732 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7741 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7745 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    7753 7636 ? 7576 999 salt /usr/bin/python
    /usr/bin/salt-master
    16961 1 ? 16961 0 root python /usr/bin/salt-api
    16966 16961 ? 16961 0 root python /usr/bin/salt-api


    W dniu sobota, 31 stycznia 2015 19:19:02 UTC+1 użytkownik Stephen Spencer
    napisał:
    Interesting. So the salt-api.pid indicates it is aware of the salt user.
    Does it show up as owned by root in the process table?

    -S

    On Wed, Jan 28, 2015 at 1:25 AM, Sławomir Kowalski <sua...@gmail.com>
    wrote:
    Hello Stephen.

    Here's the problem:
    my salt-master already runs as non-root user.
    And salt-api runs as root. I think salt-api running as root will still
    have access to IPC sockets because they're just files and root user
    is not subject to file access permission so salt-api won't ever be denied
    access to those files.

    That's why I asked here - I'm not sure whether its a bug or salt-api
    needs to use root permissions. However as I use port >1024
    for rest_cherrypy module I don't see any reason to have salt-api running
    as superuser .


    Here's output from `sudo salt-api -l debug`:

    [DEBUG ] Reading configuration from /etc/salt/master
    [DEBUG ] Including configuration from '/etc/salt/master.d/api.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/api.conf
    [DEBUG ] Including configuration from '/etc/salt/master.d/reactor.conf'
    [DEBUG ] Reading configuration from /etc/salt/master.d/reactor.conf
    [DEBUG ] Using cached minion ID from /etc/salt/minion_id: <redacted>
    [DEBUG ] Configuration file path: /etc/salt/master
    [DEBUG ] Created pidfile: /var/run/salt-api.pid
    [DEBUG ] Chowned pidfile: /var/run/salt-api.pid to user: salt
    [ERROR ] Not loading 'rest_wsgi'. 'port' not specified in config
    [INFO ] Starting 'rest.start' api module
    [DEBUG ] SaltEvent PUB socket URI:
    ipc:///var/run/salt/master/master_event_pub.ipc
    [DEBUG ] SaltEvent PULL socket URI:
    ipc:///var/run/salt/master/master_event_pull.ipc
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGHUP.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGTERM.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Listening for SIGUSR1.
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Bus STARTING
    [INFO ] [28/Jan/2015:08:20:32] ENGINE Started monitor thread
    '_TimeoutMonitor'.

    For me it looks like it does usual stuff like chowning pids but actually
    never switches to target user.



    W dniu wtorek, 27 stycznia 2015 16:16:43 UTC+1 użytkownik Sławomir
    Kowalski napisał:
    Hello!

    I was just wondering whether it's possible to run salt-api as
    unprivileged user.
    I have salt-master running as unprivileged user, and salt-api on the
    same host
    (they share configuration files so it's probably not a misconfiguration
    on my side)

    I checked the docs and they don't indicate that there's 'user' or
    similar option.

    FYI I am running latest stable packages (Helium) versions on Ubuntu
    14.04.1

    I could probably hack init script however I doubt it's optimal to do so
    ;)

    Did I miss something or there isn't currently way to instruct salt-api
    to use another uid ?

    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the terrible
    things that happen to us come because we actually deserve them? So, now I
    take great comfort in the general hostility and unfairness of the universe.
    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedJan 27, '15 at 3:16p
activeJan 31, '15 at 9:17p
posts8
users4

People

Translate

site design / logo © 2022 Grokbase