Search code examples
linuxkernelsystem-calls

Unexpected mount syscalls when running sudo command

I'm working on a program that monitors for mount and unmount syscalls and prints the various arguments of the calls to the terminal. It works ok but I noticed some behaviour that I don't understand where other commands on the system seem to trigger the mount/umount syscalls with parameters that don't make sense.

For example, using bpftrace, I run this command: bpftrace -e 'tracepoint:syscalls:sys_enter_mount { printf("%s %s %s %s\n", comm, str(args->dev_name), str(args->dir_name), str(args->type)) }' . Now if I run a mount command (e.g. mount /dev/nvme0n1p1 /home/tests) the output on the terminal is as I expect:

[root@rhel9-vm]# bpftrace -e 'tracepoint:syscalls:sys_enter_mount { printf("%s %s %s %s\n", comm, str(args->dev_name), str(args->dir_name), str(args->type)) }'
Attaching 1 probe...
mount /dev/nvme0n1p1 /home/tests xfs

If I open another terminal and try to run any sudo command, I get a lot of mount syscalls with empty or unexpected arguments:

[root@rhel9-vm]# bpftrace -e 'tracepoint:syscalls:sys_enter_mount { printf("%s %s %s %s\n", comm, str(args->dev_name), str(args->dir_name), str(args->type)) }'
Attaching 1 probe...
(fprintd)  / 
(fprintd) / /proc/self/fd/3 
(fprintd) /run/systemd/inaccessible/chr /proc/self/fd/4 
(fprintd) /run/systemd/inaccessible/dir /proc/self/fd/4 
(fprintd) proc /proc/self/fd/4 proc
(fprintd) /run/systemd/unit-root/proc/acpi /proc/self/fd/4 
(fprintd) /run/systemd/unit-root/proc/asound /proc/self/fd/4 
(fprintd) /run/systemd/unit-root/proc/bus /proc/self/fd/4 
(fprintd) /run/systemd/unit-root/proc/fs /proc/self/fd/4 
(fprintd) /run/systemd/unit-root/proc/irq /proc/self/fd/4 
(fprintd) /run/systemd/inaccessible/reg /proc/self/fd/4 
(fprintd) /run/systemd/inaccessible/reg /proc/self/fd/4 
(fprintd) /run/systemd/inaccessible/reg /proc/self/fd/4 
(fprintd) /run/systemd/unit-root/proc/mtrr /proc/self/fd/4 
(fprintd) /run/systemd/unit-root/proc/scsi /proc/self/fd/4 
(fprintd) /run/systemd/unit-root/proc/sys /proc/self/fd/4 
(fprintd) /run/systemd/unit-root/proc/sysrq-trigger /proc/self/fd/4 
(fprintd) /run/systemd/inaccessible/dir /proc/self/fd/4 
(fprintd) /run/systemd/inaccessible/dir /proc/self/fd/4 
(fprintd) /run/systemd/propagate/fprintd.service /proc/self/fd/4 
(fprintd) /run/systemd/inaccessible/dir /proc/self/fd/4 
(fprintd) /run/systemd/unit-root/sys/devices /proc/self/fd/4 
(fprintd) /tmp/systemd-private-69f2a28c33e74958aed8c34daf301716-fprintd.s /proc/self/fd/4 
(fprintd) /run/systemd/inaccessible/dir /proc/self/fd/4 
(fprintd) /var/lib/fprint /proc/self/fd/4 
(fprintd) /var/tmp/systemd-private-69f2a28c33e74958aed8c34daf301716-fprin /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd)  /proc/self/fd/4 
(fprintd) /run/systemd/unit-root / 
(fprintd)  / 
(fprintd)  /run/systemd/incoming

I don't understand this behaviour. Why would there be any mount syscalls for a simple sudo ls command? In the short term, I can filter out the unexpected by ignoring any that don't have the file type set but that seems like a bit of a hack. Maybe there is something in the entry flags that would explain it?

The command field (comm) from bpftrace mentions fprintd although when I look at the calls through a third party kernel driver I see systemd rhgb --switched-root --system --deserialize 31 as the command.

Is there any reasonable explanation for the behaviour I'm seeing?

Solution

  • In Linux, mount can do more than mount filesystems - there is also a "bind mount", that mounts a content of a directory to another directory - like a symlink, but different.

    In that trace we see the fingerprint scanner daemon (fprintd) prepares an isolated container: a process, that can only view a portion of the system and separated from other processes. You can read more on that function of Linux in man namespaces.

    In this case, fprintd mounts all directories it deems necessary for a future containerized process - once the container is sealed, all other files and directories will become inaccessible for that process. After that it would use pivot_root to permanently move the root to a new directory (for that process and its children).

    As to why it does that - I cannot say. It seems to be some security measure, but the intricacies of systemd is outside of my knowledge.