Title
#general
Nabil Schear

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.
6:00 PM
select * from deb_packages where mount_namespace_id in (select mnt_namespace from docker_containers);
Stefano Bonicatti

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.
Nabil Schear

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
Stefano Bonicatti

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.
Nabil Schear

Nabil Schear

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

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.
8:48 PM
nvm I indeed forgot one case
Nabil Schear

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)"}
]
Stefano Bonicatti

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.
10:12 PM
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. 😕
Nabil Schear

Nabil Schear

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

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.
10:00 AM
Just to rule out differences, what version of osquery is that? Also what distribution/version of Linux was the host?
10:00 AM
Does it reproduce consistently there?
Nabil Schear

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.
4:52 PM
for certain queries, the bug does re-produce reliably
4:52 PM
e.g., deb_packages
4:52 PM
but as i noted above os_version is fine
4:53 PM
it’s also on a 5.10 series kernel
11:20 PM
FYI: i just submitted a quick PR to fix this problem: https://github.com/osquery/osquery/pull/7139