WSA issues: module not working, superuser list isn't retained after reboot

[Thisisauser6443]

Describe the bug Granted and denied superuser list in the manager isn't retained after every reboot

To Reproduce Steps to reproduce the behaviour:

1. Grant/Deny any app (Might apply system, and possibly user-systemized, apps)
2. Do a normal reboot (I haven't tested, but soft reboots might not have a problem, as per my assumption)
3. Return to the Superuser tab in the manager
4. The Grant/Deny list, compared to before rebooting, isn't retained

Expected behaviour The list should be retained, after each reboot

Smartphone:

• Device: Windows Subsystem for Android (Pixel 5)
• OS: Android 13/API Level 33 (November 2022 Feature Drop - TP1A.221105.002)
• Version: 0.3.9 (10647)

[tiann]

please upload the log in KernelSU manager, settings - send log

[Howard20181]

Grand root permission before reboot KernelSU_bugreport_2023-02-26_14_29.tar.gz After reboot KernelSU_bugreport_2023-02-26_14_30.tar.gz

[Howard20181]

Grand root permission before reboot KernelSU_bugreport_2023-02-26_14_29.tar.gz After reboot KernelSU_bugreport_2023-02-26_14_30.tar.gz

In dmesg: KernelSU: load_allow_list open '/data/adb': -2

[tiann]

It seems that kernel can not access/write /data directory in WSL, maybe the /data has special mnt?

[Thisisauser6443]

@tiann, it's taking a little longer than I was hoping to get those logs, since the day after I reported this issue, my PC decided "Hey, I'm gonna become a useless paperweight!", so that's where I am, for now

I'm trying to reproduce the issue, on a different machine with WSA, so hopefully I can get them soon enough :)

[Thisisauser6443]

Before reboot.gz - Granted permission to com.android.shell After reboot.gz - Permission revoked from Shell

[tiann]

This issue seems to be reproducible, I will try it out on a WSL.

[rhjdvsgsgks]

i got the same issue on my device. the difference is there is no errot about opening "/data/adb". but have error on loading .allowlist/packages.list file. even selinux is permissive. and i did saw any "denied" about it. here is the part of logs:

KernelSU: load_allow_list open file failed: -2
KernelSU: do_update_uid, open /data/system/packages.list failed: -126
KernelSU: prctl reply error, cmd: 5
KernelSU: prctl reply error, cmd: 6
KernelSU: prctl reply error, cmd: 5
KernelSU: prctl reply error, cmd: 6
KernelSU: save_allow_list creat file failed: -126
KernelSU: save_allow_list creat file failed: -126
KernelSU: prctl reply error, cmd: 5
KernelSU: prctl reply error, cmd: 6

maybe because files still not decrypted at those moment? edit: still got error when saving list. at that time data already unlocked. so my guessing should be wrong (at least on the save_allow_list part)

[tiann]

i got the same issue on my device. the difference is there is no errot about opening "/data/adb". but have error on loading .allowlist/packages.list file. even selinux is permissive. and i did saw any "denied" about it. here is the part of logs:

KernelSU: load_allow_list open file failed: -2
KernelSU: do_update_uid, open /data/system/packages.list failed: -126
KernelSU: prctl reply error, cmd: 5
KernelSU: prctl reply error, cmd: 6
KernelSU: prctl reply error, cmd: 5
KernelSU: prctl reply error, cmd: 6
KernelSU: save_allow_list creat file failed: -126
KernelSU: save_allow_list creat file failed: -126
KernelSU: prctl reply error, cmd: 5
KernelSU: prctl reply error, cmd: 6

maybe because files still not decrypted at those moment? edit: still got error when saving list. at that time data already unlocked. so my guessing should be wrong (at least on the save_allow_list part)

-126 means ENOKEY, there is something wrong with keyring in your kernel, you can refer this commit: https://github.com/tiann/KernelSU/commit/0c322a33bc22e30a9fa44a5630b9f412d601376e

[Thisisauser6443]

Hm, interesting - I thought it would be due to how Hyper-V mounted data in a unique way, just like how it'll mount partitions like system and vendor as Read-Only

[Howard20181]

At least data partition should be mount as read write.

[rhjdvsgsgks]

-126 means ENOKEY, there is something wrong with keyring in your kernel, you can refer this commit: 0c322a3

actually i searched "flip_open enokey/126" before and found nothing. seems like it not very usual to seen on non android device? anyway, after enable the workaround i got a oops. should i open i new issue?

[qwerty472123]

WSA上整个Android被挂载的mnt_ns不是init_task.mnt_ns，系统调用时current的mnt_ns是正确的，而workqueue里的current的mnt_ns是init_task.mnt_ns，所以会返回-2.

[qwerty472123]

一种可能的修改（假设WSA不会像WSL那样一个内核用ns跑多个分发）：每次文件操作都找到zygote进程用它的ns和fs。

static struct workqueue_struct *test_workqueue;
static struct delayed_work test_save_work;

// 摘自 kernel/fork.c
struct file *test_get_task_exe_file(struct task_struct *task)
{
    struct file *exe_file = NULL;
    struct mm_struct *mm;
	struct file *exe_file = NULL;
	struct mm_struct *mm;

    task_lock(task);
    mm = task->mm;
    if (mm) {
        if (!(task->flags & PF_KTHREAD)) {
	task_lock(task);
	mm = task->mm;
	if (mm) {
		if (!(task->flags & PF_KTHREAD)) {
            rcu_read_lock();
            exe_file = rcu_dereference(mm->exe_file);
            if (exe_file && !get_file_rcu(exe_file))
                exe_file = NULL;
            rcu_read_unlock();
        }
    }
    task_unlock(task);
    return exe_file;
	}
	task_unlock(task);
	return exe_file;
}

void do_save_allow_list(struct work_struct *work)
{
    unsigned char path_buf[260];
    const char *path;
    struct file *fp;
    struct task_struct * p;
    bool found_zygote = false;
    struct nsproxy *ns;
    struct fs_struct *fs;
    
    read_lock(&tasklist_lock);
    for_each_process(p) {
        // 保证是 root 进程，而非非预期的用户进程
        if (task_uid(p).val != 0) {
            continue;
        }
        fp = test_get_task_exe_file(p);
        if (!fp) {
            continue;
        }
        path = d_path(&(fp->f_path), path_buf, 256);
        if (!path) {
            continue;
        }
        if (strcmp(path, "/system/bin/app_process64") && strcmp(path, "/system/bin/app_process32")) {
            continue;
        }
        if (!p->fs) {
            continue;
        }
        pr_info("test: zygote path: %s\n", path);
        found_zygote = true;
        break;
    }
    read_unlock(&tasklist_lock);
    if (!found_zygote) {
        pr_info("test: zygote not found, wait a second\n");
        queue_delayed_work(test_workqueue, &test_save_work, msecs_to_jiffies(1000));
        return;
    }
    pr_info("test: zygote found\n");

    // 切换ns和fs，不清楚要不要加锁，加锁似乎会卡住
    ns = current->nsproxy;
    current->nsproxy = p->nsproxy;
    fs = current->fs;
    current->fs = p->fs;

    fp = filp_open("/data/adb/ksu/.allowlist", O_WRONLY | O_CREAT, 0644);
    if (IS_ERR(fp)) {
        pr_err("test: failed: %ld\n", PTR_ERR(fp));
    } else {
        // 这样似乎可以打开了
        pr_err("test: success\n");
        filp_close(fp, 0);
    }

    current->nsproxy = ns;
    current->fs = fs;
}

static int test_init(void) {
    test_workqueue = alloc_workqueue("test_work_queue", 0, 0);
    INIT_DELAYED_WORK(&test_save_work, do_save_allow_list);
//...
}
//...

[tiann]

找到当前 ns 下 pid 为 1 的进程的 mnt_ns 然后在 kernel workqueue 里面切换过去应该是一个可行的办法。

[qwerty472123]

找到当前 ns 下 pid 为 1 的进程的 mnt_ns 然后在 kernel workqueue 里面切换过去应该是一个可行的办法。

具体什么是”当前ns“？

我测试的结果是workqueue的current里的ns均与init_task的一致、与android上下文只共享 user/net/time/cgroup ns，而不共享 pid namespace，因此以workqueue的current->nsproxy->pid_ns的视角来查找的pid为1的进程不是init second_stage.

[tiann]

在 ksu_load_allow_list 这个函数的 current 应该是当前进程，在它启动 workqueue 的时候把 pid namespace 或者其他传进去

[qwerty472123]

在 ksu_load_allow_list 这个函数的 current 应该是当前进程，在它启动 workqueue 的时候把 pid namespace 或者其他传进去

See comment in #698

[DocMAX]

I have similar issue:

[ 6798.319278] KernelSU: handle umount for uid: 10122, pid: 12203
[ 6799.079620] KernelSU: handle umount for uid: 10122, pid: 12265
[ 6799.361296] KernelSU: handle umount for uid: 10113, pid: 12291
[ 6799.392866] KernelSU: handle umount for uid: 10113, pid: 12310
[ 6800.019151] KernelSU: handle umount for uid: 10117, pid: 12400
[ 6800.234478] KernelSU: handle umount for uid: 10113, pid: 12428
[ 6800.483050] KernelSU: handle umount for uid: 10121, pid: 12454
[ 6810.038895] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[ 6810.039104] KernelSU: do_update_uid, open /data/system/packages.list failed: -13
[ 6900.118201] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[ 6900.118399] KernelSU: do_update_uid, open /data/system/packages.list failed: -13
[ 6903.803991] KernelSU: handle umount for uid: 10090, pid: 12879
[ 6913.802788] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[ 6913.802955] KernelSU: do_update_uid, open /data/system/packages.list failed: -13
[ 6921.684839] KernelSU: set root profile, key: com.android.shell, uid: 2000, gid: 0, context: u:r:su:s0
[ 6921.686631] KernelSU: save_allow_list create file failed: -13
[ 7151.023566] KernelSU: volumedown_pressed_count: 0

KernelSU_bugreport_2023-12-29_16_07.tar.gz

[qwerty472123]

@DocMAX -13 mean no permission to do that(open that file), rather than not exists.

you may check why kernel worker have no permission to open these files.