hi folks, has anyone successfully used the `mount_...
# general
hi folks, has anyone successfully used the
feature of various tables like
? 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
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.
Copy code
select * from deb_packages where mount_namespace_id in (select mnt_namespace from docker_containers);
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.
while, you’re here… seen this before?
Copy code
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
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.
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
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
some of the namespace things work on the same system. Like
Copy code
$ 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)"}
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
I should note that mount_namespace is RO. I'm not sure we have clear conventions for that. :/
@Stefano Bonicatti is this an easy fix to correct?
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?
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