5

I am still new to understanding chroot. Some packages install their own users (_packagedaemon) and create their own directories (/var/package/).

However, I cannot tell if the process is configured to run in a chroot, and I'm not sure where to check.

Paul
  • 507
  • 3
    There's some initial confusion here; an account isn't chroot'ed, a process is. Can you [edit] your question to spell out your actual concern around users & chroots? – Jeff Schaller Jul 14 '21 at 18:18
  • @JeffSchaller Thank you, that helps a lot! I think now where I'm having issues in rewriting the question is that I'm evaluating a few different packages written in python or Go. A Go package seems more likely to be what I install, but I'm new to having Go on a server, and since I haven't configured everything, yet, I'm trying to determine if it runs in a chroot, and rcctl ls all lists packagename, though it isn't on. – Paul Jul 14 '21 at 18:40
  • 3
    ls -l /proc/PID/root tells you the root of process PID. I have the feeling, though, that your question is not about a running process, but a script or a binary executable that is not (yet) running. I don't think there is a general method to find out whether a program might get chrooted. It's obviously easier to analyze a script (Python) than a binary (Go). – berndbausch Jul 14 '21 at 23:06
  • 1
    @berndbausch Thanks. I'll get it up and running and see what happens. Note, however, this question is for OpenBSD, but the Linux command is still useful to know. – Paul Jul 15 '21 at 02:33
  • I missed the OpenBSD part. I don't know if the BSDs have /proc or something equivalent. – berndbausch Jul 15 '21 at 08:22
  • 1
    From rcctl's man page: ls all will list all installed daemons, ls on lists enabled daemons (i.e. should be running), ls started lists running daemons. – Zé Loff Jul 15 '21 at 10:13

1 Answers1

5

fstat will indicate where a (running) process is rooted.

Example 1: nginx

nginx's workers run chrooted. You can use pgrep get the process' ID:

# pgrep -lf nginx
58845 nginx: worker process
41019 nginx: master process /usr/local/sbin/nginx

and then use fstat to check which files/sockets it has open:

# fstat -p 58845 | grep -e MODE -e " root"
USER     CMD          PID   FD MOUNT        INUM  MODE         R/W    SZ|DV
www      nginx      58845 root /var/www        2  drwxr-xr-x     r      512

This line, the one with root in the FD column, indicates that the process is rooted on inode 2 (INUM column) of mount point /var/www. You can then find out that node's name using find:

# find -x /var/www -inum 2
/var/www

So, in this case, nginx's workers are chrooted to /var/www. Note that the master process doesn't run chrooted:

# fstat -p 41019 | grep " root"

comes up empty. The master process reads all config files and then forks chrooted workers.

Example 2: nsd

nsd is a bit different from nginx, as even the main process runs chrooted in /var/nsd:

# pgrep -lf nsd
28155 nsd: server 1
45373 nsd: main
3681 nsd: xfrd

fstat -p 45373 | grep -e MODE -e " root"


USER     CMD          PID   FD MOUNT        INUM  MODE         R/W    SZ|DV
_nsd     nsd        45373 root /var         8580  drwxr-xr-x     r      512


find -x /var -inum 8580


/var/nsd
Paul
  • 507
Zé Loff
  • 2,112
  • 2
    I think OpenBSD default httpd might be slightly better as an example, because fstat output for logger and server for root has MOUNT as /var and (in my case) INUM 570240, making it clearer why I need to run # find -x /var -inum 570240 (output is /var/www). – Paul Jul 15 '21 at 11:53
  • 1
    Yes, but none of my machines are running httpd, so I couldn't use it as an example :) That is also why I included the nsd example, not only the main process is chrooted, but you also need to use find to get the inode. Since I have /var/www as a separate mount point, the first example might not make that clear enough. – Zé Loff Jul 15 '21 at 12:19
  • 1
    Indeed, I missed that rather relevant detail. I just tested on a server with nginx, and it reported /var so I had to find the reported INUM. Another good one is smtpd, if you happen to run that one pgrep outputs a lot of different processes. – Paul Jul 15 '21 at 13:16