2

I've been Googling all over trying to find an answer to this, and trying to mentally parse initialization scripts to find where it's done, to no avail.

I just did a ps and pulled a random example. I have a process that appears as follows:

polkitd 1230 1 0 May07 ? 00:00:00 /usr/lib/polkit-1/polkitd --no-debug

looking at my /etc/passwd, I see:

polkitd:x:87:87:PolicyKit daemon owner:/var/lib/polkit:/bin/false

As a test, I run a command as root: # su - polkitd -c whoami Which returns no output, as expected due to it having /bin/false as a shell. Additionally, # su - polkitd does not switch me to polkitd. To make sure I was doing this correctly, I tested both of these with a normal user account and both worked as they should.

So, how is it that a dedicated account such as polkitd in my example can be made to run a process, when you seemingly can't make it run anything at all manually?

2

root can become polkitd via an appropriate system call, e.g. seteuid(2) as can be demonstrated with

$ cat becomepolkit.c 
#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    // ID obtained via `id polkitd` on a Centos7 system
    // other systems may vary
    seteuid(999);

    printf("look for %d in process list\n", getpid());

    sleep(99999);

    return 0;
}
$ make becomepolkit
cc     becomepolkit.c   -o becomepolkit
$ sudo ./becomepolkit &
[1] 10914
$ look for 10915 in process list

$ ps auwwx | grep '1091[5]'
polkitd  10915  0.0  0.0   4160   340 pts/0    S    22:46   0:00 ./becomepolkit
$ 

Usually root via the init system (e.g. systemd) or cron will launch a process as root, and then change the user of the process; no shell access is required for this to happen. You can observe this for an arbitrary process by running the process under strace or some other tracing tool:

sudo strace -o blah ./becomepolkit
look for 10968 in process list
^C$ grep 999 blah
setresuid(-1, 999, -1)                  = 0
nanosleep({99999, 0}, {99997, 670178798}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
$ 

So here Linux is actually using the setresuid(2) call but same difference, the process will show up as polkitd in the process table.

2

The login shell of a user is the program that most login programs invoke when the user has authenticated (typically by entering their name and password). Login programs include login (for logging in on a text console), sshd (for logging in over the network), su (for logging in from another account), etc.

Login programs can choose to run whatever they choose. The fact that most of them run the user's login shell is an administrative decision more than a technical constraint. A class of login programs that does not follow this convention is display managers, i.e. programs that log the user in in graphical mode: these typically execute a /bin/sh script such as /etc/X11/Xsession.

System services are typically not invoked by login programs at all. They're invoked automatically by a daemon launcher which is running with administrative privileges; starting a system service does not require any authentication. (For a user to request starting a system service typically requires authentication, to become root.) So the login shell is not involved at all, there would be no reason to involve it.

Daemon launchers (my terminology for the purpose of this answer) include systemd, start-stop-daemon, runuser, etc.

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.