fsconfig
내 커널 모듈에서는 읽기 전용 마운트 지점을 다시 마운트하는 것과 관련된 작업을 관리하는 시스템 호출 후크를 구현했습니다 . 예를 들어 사용자가 실행하면 후크 내부의 문자열을 추출해야 합니다 mount /dev/sda /tmp/mytest -o remount,ro
./tmp/mytest
fsconfig
이를 달성하기 위해 파일 설명자를 통해 구조에 액세스하는 커널 fs_context
의 방법을 조사했습니다. 내 목표는 fsconfig 시스템 호출 중에 이 구조를 통해 마운트 지점 경로를 검색하는 것입니다.
dentry_path_raw
처음에는 start from 과 같은 함수를 사용해 보았지만 fc_context->dentry
결과 문자열은 단순하여 "/"
내 요구 사항에 맞지 않았습니다. 또한 를 사용하여 탐색했지만 시스템 호출에서 액세스할 수 없는 및 를 포함하는 구조가 d_path
필요하므로 이 접근 방식은 실용적이지 않습니다.path
dentry
vfsmount
vfsmount
fsconfig
__is_local_mountpoint
마지막으로 커널 소스 코드에서 이 함수를 찾았습니다.(fs/namespace.c). 이 함수는 current를 통해 현재 작업의 네임스페이스에 액세스하여 모든 마운트 지점을 반복하도록 제안합니다. 이 코드를 적용하여 각 마운트 지점의 mnt_root를 fs_context 루트와 비교하고 해당 마운트를 성공적으로 식별했습니다. 코드는 여기에 있습니다.
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);
namespace_sem
그러나 네임스페이스.c에서 를 사용하는 데에는 심각한 문제가 있습니다. namespace_sem
static( ) 으로 선언하면 static DECLARE_RWSEM(namespace_sem);
모듈 내부에 직접 접근할 수 없으며 잠재적인 위험이 있음을 의미합니다.
이제 내 주요 질문은 다음과 같습니다.
fs_context
커널 코드를 수정하지 않고 마운트 지점 경로를 얻는 안전한 방법이 있습니까? (fs_context
항상 마운트된 파일 시스템에 해당한다고 가정합니다.)- 마운트 지점 반복으로 제한되는 경우 세마포어에 안전하게 액세스할 수 없다는 문제를 어떻게 해결합니까?
(커널 버전 >= 6.6이라고 가정할 수 있습니다.)