How to get full mountpoint path name by the sturct fc_context

21 views Asked by At

In my kernel module, I've implemented a syscall hook named fsconfig to manage operations related to remounting readonly mountpoints. For instance, if a user executes mount /dev/sda /tmp/mytest -o remount,ro, I need to extract the string /tmp/mytest within the fsconfig hook.

To achieve this, I explored the kernel's approach of accessing an fs_context structure via a file descriptor. My goal is to retrieve the mount point path through this structure during the fsconfig syscall.

Initially, I attempted to utilize functions like dentry_path_raw starting from fc_context->dentry, but the resulting string was simply "/", which didn't fulfill my requirements. I also explored using d_path, but it necessitated a path structure containing dentry and vfsmount, which vfsmount isn't accessible within the fsconfig syscall, rendering this approach impractical.

Finally, I came across the __is_local_mountpoint function in the kernel source code (fs/namespace.c). This function suggests iterating through all mountpoints by accessing the namespace of the current task via current. I adapted this code to compare the mnt_root of each mountpoint with the fs_context root, successfully identifying the corresponding mount, the code is here.

ns =  current->nsproxy->mnt_ns;
lock_ns_list(ns);
list_for_each_entry(mnt, &ns->list, mnt_list) {
    if (fc->root == mnt->mnt.mnt_root) {
        target_dentry = mnt->mnt.mnt_root;
        path.dentry = target_dentry;
        path.mnt = &mnt->mnt;
        break;
    }
}
unlock_ns_list(ns);

However, there's a significant concern regarding the usage of namespace_sem in namespace.c. The declaration of namespace_sem is static (static DECLARE_RWSEM(namespace_sem);), meaning it cannot be accessed directly within the module, posing potential risks.

Now, my primary questions are:

  1. Is there a secure method to obtain the mount point path through fs_context without requiring modifications to kernel code? (Assuming fs_context always corresponds to a mounted file system.)
  2. If we're limited to iterating through mountpoints, how can we address the challenge of not being able to access the semaphore securely?

(Its can be assumed the kernel version >= 6.6.)

0

There are 0 answers