analyzer: add pre-container monitor to capture early file access#2129
analyzer: add pre-container monitor to capture early file access#2129ktock merged 1 commit intocontainerd:mainfrom
Conversation
wswsmao
force-pushed
the
monitor
branch
2 times, most recently
from
e363684 to
71e7abd
Compare
Signed-off-by: abushwang <[email protected]>
| prePaths := preMonitor.GetPaths() | ||
| for _, path := range prePaths { | ||
| cleanPath := path | ||
| if strings.HasPrefix(path, target) { |
There was a problem hiding this comment.
Is it possible that this becomes false? If so, that path should not be recorded and just be skipped.
There was a problem hiding this comment.
I investigated this on nvcr.io/nvidia/tritonserver:25.07-py3 and found that during the pre-monitor phase fanotify can report the same file in two forms: with and without the target mount prefix. For example:
- Without prefix:
/usr/lib/x86_64-linux-gnu/libubsan.so.1.0.0/usr/lib/x86_64-linux-gnu/liblber.so.2.0.200/opt/hpcx/ompi/lib/libpmix.so.2.2.35
- With prefix:
/tmp/target296403442/usr/bin/nvidia-persistenced/tmp/target296403442/usr/lib/firmware/nvidia/535.261.03/gsp_ga10x.bin
After the container starts, these files are present in the container filesystem as expected:
# inside the running container
ls /usr/lib/x86_64-linux-gnu/libubsan.so.1.0.0 \
/usr/lib/x86_64-linux-gnu/liblber.so.2.0.200 \
/opt/hpcx/ompi/lib/libpmix.so.2.2.35
# outputs: all three paths exist
ls /usr/bin/nvidia-persistenced \
/usr/lib/firmware/nvidia/535.261.03/gsp_ga10x.bin
# outputs: both paths exist
So strings.HasPrefix(path, target) can legitimately be false for valid accesses under the rootfs. If we skip those, we will miss real file accesses.
The safer approach is to normalize: when the prefix is present, trim it; otherwise record the path as-is. Even if there is a non-existent file, recorder.Record will skip it here.
2 participants
Fixes: #2128