Add inum (mount namespace id) for clone, unshare, mount, umount, umount2, open, openat, openat2

[albe19029]

Good day. In our application that use your driver sometimes we need additional information from mountinfo file. We need information both for host and containers. What we want is to enter every mount namespace once and read information from it. And then with monitoring mount and umount events just to maintain this in memory. The problem is that for now in mount and umount events from driver we don't see for what namespace this operations are executed.

Maybe it is possible to add task->nsproxy->mnt_ns->ns->inum to clone, unshare, mount, umount, umount2, open, openat, openat2 events. In this case we will see every operation with mount namespace (create: clone, unshare with CLONE_NEWNS, change: mount, umount, umount2) and provide additional information about filesystem on every file open access.

[albe19029]

By the way. We read information from /proc/self/mountinfo because it is the only place where shared subtrees information exists in user space (https://man7.org/linux/man-pages/man7/mount_namespaces.7.html#SHARED_SUBTREES). In this case when we see mount or umount syscalls we can changes not only information in original mount point, but also in other mount point dependent on relationships between this namespaces.

[albe19029]

As an alternative to monitoring all mount point state it is also just possible to put filesystem type for open, openat, openat2 syscalls?

As I can see there are already get_fd_dev_ino method with get ino an dev for some reason. And getting sb->s_type->name can be useful for customers as well?

[albe19029]

Is it a chance that this can be implemented?

[Andreagit97]

ei @albe19029 thank you for the request! Ideally, we would like to capture all possible info from the kernel, but of course, there is a price to pay, mainly in performance. open family syscalls are really frequent so we need to pay attention to what we add. The moun

Regarding the mount namespace ID, at the moment, I don't see a widespread use case for our libraries, even if I see the value in having it. On the other side, the filesystem type is something we were already considering adding, so yes this is something that could happen, but I can't give you an ETA right now.

I will put the milestone TBD ("To be defined") to mark this as a meaningful request but without a precise ETA. BTW thank you for the feature request it definitely makes sense

/milestone TBD

[albe19029]

Thanks a lot. Adding filesystem type to open syscalls (sb->s_type->name) will be enough. As s_dev from mountinfo is already there, and monitoring mountinfo only need for us to get filesystem type.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale