1

CentOS here, but I don't think that matters because this should be a core Linux question (methinks). While trying to install & run Apache Kafka (a Java executable) on a CentOS box, I thought of a question that applies to Linux in general.

When you run a shell script or a native executable (such as java), does the script/executable dictate which user it runs as, or does the OS dictate which user the script/executable runs as (meaning, which ever user is executing the script/executable)?

Is it possible and/or typical for processes to dictate which user they run as? Meaning can a script/application specify that it must run as root user, or as some other specific type of user?

Either way, why is there a general admonishment about running processes as root vs running them as non-privileged users?

4

Short answer: both.

Longer (and much more useful) answer: By default, the program will run as the user who launched it. However, a program can, if written to do so and given the correct permissions, assume root privileges and/or drop back down to a "system" user to run itself as. This ability must be explicitly bestowed on the program, though, either through the packaging and installation process or through actions taken by the administrator of that machine.

The general admonishment is there because historical experience in UNIX and Linux has shown that quite often programs that use elevated (i.e. root) privileges that they do not need will often do bad things to the system. This can be from data corruption, to runaway processes that render the rest of the system unusable / unresponsive, to processes that unwittingly allow attackers access to your system in ways that you don't want them to.

  • 1
    Just to add a practical example to this, Take a web page running on apache. The preferred way for this to run is to run as the apache user, if you were to set things up in such a way that apache was running as root however, any vulnerabilities in apache or your website become that much worse. If something happens that causes a user on the web to gain access to the apache service, they then gain root control of the entire system, rather then being locked in the apache box. Any process on the system should always have JUST enough privilege to do what it needs to do, and not a drop more. – Gravy Sep 28 '16 at 15:15
  • Thanks for the great answer @John (+1) - a quick followup question if you don't mind. I think I'm hearing that programs can be coded to require being ran as root (so they can read/write things under, say, /opt, etc.) but that coding them that way would be a deeply discouraged practice for security purposes, yes? Thanks again! – smeeb Sep 28 '16 at 15:25
  • 2
    Discouraged, yes. Deeply discouraged, depends on who you're talking to. It's called the "Principle of Least Privilege" - do whatever you have to do with the least amount of privilege required to get the job done, and no more. Why would you give the painter a key to your house when he's only painting the outside? Why would you give the lawn maintenance people access to your indoor hot tub or pool? That same reasoning applies to programs. – John Sep 28 '16 at 15:28
  • John's right about privileges and discouragement of using root. It's absolutlely worth considering that if you're only trying to figure out how to build a model hot tub in your basement, healthy as it is to learn best practices, you don't need to go overboard. I've known people starting out who spent weeks trying to learn about security, when they only needed to spend a couple of hours trying to learn how the service works in the first place. – Stephan Sep 28 '16 at 20:25
0

When a 'shell script' is executed, it's executed with the permissions of the user that executed that script. Most services (kafka, redis, nginx, etc) installed using a package manager (yum, apt, etc) install helper scripts to facilitate the control of those services, and create unique service users associated with those services (apache, redis, nginx, etc.) Nearly all of these helper scripts are executed as root initially, and then drop privileges to a service user assigned to that service. This ensures that only authorized users (i.e. users who are authorized to execute "sudo service kafka start") can effectively control those services. This means sysadmin Sally can start, stop, and restart kafka and nginx, while developer Jim may be restricted to only starting and stopping kafka (or some such.) While a java user may be created by the administrator, it's not something I've seen in practice, any more than a ruby user or a python user. Rather, the service ownership is more often pinned to a service user related to that particular service.

Some processes depend on being run as root (usually the ssh server daemon is run as root.) Other processes will refuse to start as root (postgresql is one.)

If you review a helper script for a service at /etc/init.d/someservice (or /etc/init/someservice.conf) the actual scripting that causes privilege escalation or drops are coded there. Alternatively, if you're logged in as user stephan, and execute something like /usr/sbin/redis-server -c /etc/redis.conf, then check on that process from another window, you'll see that redis is owned by stephan.

Hope that helps.

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.