https://github.com/osquery/osquery logo
Title
n

Nabil Schear

05/20/2021, 6:00 PM
hi folks, has anyone successfully used the
mount_namespace_id
feature of various tables like
deb_packages
? I have a docker container running and would like to be able to query the packages installed in the container. I am able to accomplish this using
pid_with_namespace
and passing in a pid from the container. However, passing in the mount namespace id from
select mnt_namespace from docker_containers;
returns no results.
select * from deb_packages where mount_namespace_id in (select mnt_namespace from docker_containers);
s

Stefano Bonicatti

05/20/2021, 8:34 PM
the
mount_namespace_id
it’s only there to be reported, it doesn’t let you join a namespace. Unfortunately the underlying API used on Linux to join a namespace (to be able to query things inside it) requires a pid.
n

Nabil Schear

05/20/2021, 8:35 PM
while, you’re here… seen this before?
sudo osqueryi --json "select * from deb_packages where pid_with_namespace in (select pid from docker_containers where name='/c4bed2da-c9d7-4394-98f4-ec5b89a071fa');" | jq
E0520 18:10:24.668191 4093640 linux_table_container_ipc.cpp:443] Table deb_packages failed to retrieve QueryData from the container: Failed to read the entire message from the pipe of table deb_packages, read only 62020/90692 bytes
s

Stefano Bonicatti

05/20/2021, 8:36 PM
I’m not saying it’s totally impossible, but it would require a scan of /procs to find a pid that has the same namespace you’re searching for, but then it might be a short lived process, so it’s not ideal.
n

Nabil Schear

05/20/2021, 8:36 PM
looking at that code, i’m wondering if it should just be reading in a loop
but i’ve only glanced at it
no problem re mnt_namespace, i just mis-understood what it was for. Will use pid_with_namespace instead
s

Stefano Bonicatti

05/20/2021, 8:46 PM
Hum interesting for the pipe error, in theory being it blocking it shouldn’t yield reading; it also didn’t seem to receive a signal, otherwise it would’ve exited with a negative value (and the error would’ve been different). I will test it.
nvm I indeed forgot one case
n

Nabil Schear

05/20/2021, 8:52 PM
some of the namespace things work on the same system. Like
$ sudo osqueryi --json "select * from os_version where pid_with_namespace in (select pid from docker_containers where name='/c4bed2da-c9d7-4394-98f4-ec5b89a071fa');"
[
  {"arch":"x86_64","build":"","codename":"bionic","major":"18","minor":"4","name":"Ubuntu","patch":"0","platform":"ubuntu","platform_like":"debian","version":"18.04.5 LTS (Bionic Beaver)"}
]
s

Stefano Bonicatti

05/20/2021, 8:57 PM
yeah it’s due to a signal interrupting the read while it has already read some bytes.. a rookie mistake on my part.
although I wonder what's the signal
s

seph

05/20/2021, 10:26 PM
I should note that mount_namespace is RO. I'm not sure we have clear conventions for that. :/
n

Nabil Schear

05/20/2021, 11:14 PM
@Stefano Bonicatti is this an easy fix to correct?
s

Stefano Bonicatti

05/21/2021, 9:42 AM
I have to investigate what is really interrupting it, because on a second look yes, a signal can interrupt it, but if any signal is received, the read should not continue, since it has likely been asked to yield and exit.
Just to rule out differences, what version of osquery is that? Also what distribution/version of Linux was the host?
Does it reproduce consistently there?
n

Nabil Schear

05/21/2021, 4:51 PM
hi, sorry i missed this earlier. this is ubuntu 18.04 with osquery 4.8.0. It’s a host running our Titus container platform (https://netflix.github.io/titus/), so it’s pretty heavily customized.
for certain queries, the bug does re-produce reliably
e.g., deb_packages
but as i noted above os_version is fine
it’s also on a 5.10 series kernel
FYI: i just submitted a quick PR to fix this problem: https://github.com/osquery/osquery/pull/7139