How does syzkaller fully fuzz the kernel file system as an untrusted_app?

[tr4v3ler]

I have reviewed the relevant code and found that syzkaller performs privilege dropping in the do_sandbox_android function to acquire the identity of untrusted_app. During this process, it also obtains a mount namespace via the unshare system call, and then mounts the target file system using syz_mount_image. After that, it creates files under the mount point and performs system calls on them.

My question is: the files created in this way may be subject to SELinux policy restrictions when accessed by untrusted_app, potentially causing certain system calls to fail. However, there may exist other files elsewhere in the system, belonging to the same file system, on which untrusted_app faces fewer access restrictions due to different SELinux contexts. As a result, more system calls could succeed on those files.

Therefore, can syzkaller truly and fully fuzz the kernel file system as an untrusted_app?