KSU report "not installed" on installed system, but "installed" on Live boot when using BlissOS

[hmtheboy154]

Please check before submitting an issue

• [X] I have searched the issues and haven't found anything relevant
• [X] I will upload bugreport file in KernelSU Manager - Settings - Report log
• [X] I know how to reproduce the issue which may not be specific to my device

Describe the bug

Recent KernelSU version report "not installed" on BlissOS when the OS is installed. On Live Boot, it works normally and report the version on the KernelSU Manager app.

To Reproduce

1. Get a BlissOS build with recent KernelSU in the kernel & Manager https://sourceforge.net/projects/blissos-x86/files/Official/BlissOS16/FOSS/Go/Bliss-Go-v16.9.5-x86_64-OFFICIAL-foss-20240529.iso/download https://drive.google.com/file/d/1tQAVbIygV4DqEyDpmGxsssF2whASzgK0/view?usp=sharing https://drive.google.com/file/d/19m0UOp70ZiNp74MHNswfjGsyqPdexDWP/view?usp=sharing

2. Install it on a VM or baremetal

3. Check KernelSU Manager

Expected behavior

It should work & report the version

Screenshots

report "not installed" on installed system

report "installed" on Live boot

currently where it keep looping

Logs

none, logs on the Manager can not dump anything

Device info

• Device: Any x86_64-v2 devices
• OS Version: BlissOS 14/15/16
• KernelSU Version: 0.9.4 (11863)
• Kernel Version: 6.1.84

Additional context

According to the screenshot, it's being looped here: https://github.com/tiann/KernelSU/blob/main/kernel/core_hook.c#L189

[hmtheboy154]

@tiann latest versions are even worse when in Live Boot, even though it said working, granting Termux can't be able to use su command

[hmtheboy154]

I've downgraded to 0.9.2 and it's actually recognized on installed system, starting to build on 0.9.3 is when the bug start happenening

[CanerKaraca23]

I've downgraded to 0.9.2 and it's actually recognized on installed system, starting to build on 0.9.3 is when the bug start happenening

Did you tried 0.9.5?

[hmtheboy154]

I've downgraded to 0.9.2 and it's actually recognized on installed system, starting to build on 0.9.3 is when the bug start happenening

Did you tried 0.9.5?

yes. Even 1.0

[hamjin]

Which dentry is NULL? old_dentry or new_dentry？

[hmtheboy154]

Which dentry is NULL? old_dentry or new_dentry？

It's been a while so I forgot, I'll check back when I got time

[hmtheboy154]

Update: I pulled KSU to latest commit currently (9bcdff1) and boot in debug mode, it still not recognize the manager. There's some output on the console though

console:/ # dmesg -w | grep KernelSU                                           
[    0.916158] KernelSU: *************************************************************
[    0.916160] KernelSU: **     NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE    **
[    0.917040] KernelSU: **                                                         **
[    0.917878] KernelSU: **         You are running KernelSU in DEBUG mode          **
[    0.918737] KernelSU: **                                                         **
[    0.919624] KernelSU: **     NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE    **
[    0.920658] KernelSU: *************************************************************
[    0.922675] KernelSU: sucompat: execve_kp: 0
[    0.924856] KernelSU: sucompat: newfstatat_kp: 0
[    0.925533] KernelSU: sucompat: faccessat_kp: 0
[    0.926440] KernelSU: sucompat: devpts_kp: 0
[    0.926519] KernelSU: ksud: execve_kp: 0
[    0.927568] KernelSU: ksud: vfs_read_kp: 0
[    0.928789] KernelSU: ksud: input_event_kp: 0
[    3.527695] KernelSU: /system/bin/init argc: 2
[    3.527698] KernelSU: /system/bin/init first arg: selinux_setup
[    4.690941] KernelSU: /system/bin/init argc: 2
[    4.690943] KernelSU: /system/bin/init first arg: second_stage
[    4.690943] KernelSU: /system/bin/init second_stage executed
[    4.690957] KernelSU: SELinux permissive or disabled, apply rules!
[    4.697879] KernelSU: android context saved disabled
[    4.885659] KernelSU: /system/bin/init argc: 4
[    4.891864] KernelSU: vfs_read: /system/etc/init/atrace.rc, comm: init, count: 1024, rc_count: 351
[    4.892422] KernelSU: read_iter_proxy append 673 + 351
[    4.892429] KernelSU: unregister vfs_read kprobe: 1!
[    4.892434] KernelSU: unregister vfs_read kprobe: 0!
[    4.892436] KernelSU: unregister vfs_read kprobe: 0!
[    4.892437] KernelSU: unregister vfs_read kprobe: 0!
[    4.892458] KernelSU: unregister vfs_read kprobe: 0!
[    4.892465] KernelSU: unregister vfs_read kprobe: 0!
[    4.892468] KernelSU: unregister vfs_read kprobe: 0!
[    4.892470] KernelSU: unregister vfs_read kprobe: 0!
[    4.892473] KernelSU: unregister vfs_read kprobe: 0!
[    4.892478] KernelSU: unregister vfs_read kprobe: 0!
[    4.892480] KernelSU: unregister vfs_read kprobe: 0!
[    4.892491] KernelSU: unregister vfs_read kprobe: 0!
[    4.892493] KernelSU: unregister vfs_read kprobe: 0!
[    4.892498] KernelSU: unregister vfs_read kprobe: 0!
[    4.892500] KernelSU: unregister vfs_read kprobe: 0!
[    4.892502] KernelSU: unregister vfs_read kprobe: 0!
[    4.892504] KernelSU: unregister vfs_read kprobe: 0!
[    4.892513] KernelSU: unregister vfs_read kprobe: 0!
[    4.892515] KernelSU: unregister vfs_read kprobe: 0!
[    4.892516] KernelSU: unregister vfs_read kprobe: 0!
[    4.892520] KernelSU: unregister vfs_read kprobe: 0!
[    4.892525] KernelSU: unregister vfs_read kprobe: 0!
[    4.892527] KernelSU: unregister vfs_read kprobe: 0!
[    4.892581] KernelSU: unregister vfs_read kprobe: 0!
[    4.892585] KernelSU: unregister vfs_read kprobe: 0!
[   11.512477] KernelSU: exec app_process, /data prepared, second_stage: 1
[   11.512488] KernelSU: on_post_fs_data!
[   11.512497] KernelSU: unregister input kprobe: 1!
[   11.512502] KernelSU: devpts sid: 638
[   11.512504] KernelSU: unregister execve kprobe: 1!
[   11.512513] KernelSU: Unsupported profile version: 0
[   11.512518] KernelSU: Failed to set app profile: invalid profile!
[   11.512553] KernelSU: load_allow_list open file failed: -2

[hmtheboy154]

The same log does show up on Live boot, but it actually continue find the manager

[   18.616524] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   18.623490] KernelSU: Searching manager...
[   18.623507] KernelSU: Search manager finished
[   28.677255] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   28.686915] KernelSU: Searching manager...
[   28.686957] KernelSU: Search manager finished
[   32.491071] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   32.498248] KernelSU: Searching manager...
[   32.498274] KernelSU: Search manager finished
[   36.313269] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   36.318839] KernelSU: Searching manager...
[   36.318872] KernelSU: Unknown id: 0x42726577
[   36.318874] KernelSU: Unexpected v3 signature scheme found!
[   36.318875] KernelSU: Found new base.apk at path: /data/app/~~N-zSbZIhNrUyGH03qJy_Cw==/com.termux-c41V9Ag0oAST8BJLiVk3zw==/base.apk, is_manager: 0
[   36.318886] KernelSU: Unknown id: 0x504b4453
[   36.318887] KernelSU: Unknown id: 0x42726577
[   36.318888] KernelSU: Found new base.apk at path: /data/app/~~iz2FDWukoEBo5TfjpTJHkQ==/com.amaze.filemanager-rxf6UxLNEJwlv_5zgegrXQ==/base.apk, is_manager: 0
[   36.318890] KernelSU: Search manager finished
[   36.969531] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   36.976644] KernelSU: Searching manager...
[   36.976705] KernelSU: sha256: c371061b19d8c7d7d6133c6a9bafe198fa944e50c1b31c9d8daa8d7f1fc2d2d6, expected: c371061b19d8c7d7d6133c6a9bafe198fa944e50c1b31c9d8daa8d7f1fc2d2d6
[   36.976707] KernelSU: Unknown id: 0x504b4453
[   36.976708] KernelSU: Unknown id: 0x42726577
[   36.976732] KernelSU: Found new base.apk at path: /data/app/~~gbnxVANZr-B4M7dU3px2RA==/me.weishu.kernelsu-zw7nokylm5JUIKLNI7Ptfw==/base.apk, is_manager: 1
[   36.976734] KernelSU: manager pkg: me.weishu.kernelsu
[   36.976736] KernelSU: Crowning manager: me.weishu.kernelsu(uid=10251)
[   36.976737] KernelSU: Search manager finished
[   37.417133] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   38.070150] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   39.238175] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list

[hmtheboy154]

Which dentry is NULL? old_dentry or new_dentry？

So with the help of ChatGPT, I made a patch to print some more info to debug:

diff --git a/kernel/core_hook.c b/kernel/core_hook.c
index b63ea0b1..0fada79b 100644
--- a/kernel/core_hook.c
+++ b/kernel/core_hook.c
@@ -167,41 +167,55 @@ void escape_to_root(void)
 
 int ksu_handle_rename(struct dentry *old_dentry, struct dentry *new_dentry)
 {
-	if (!current->mm) {
-		// skip kernel threads
-		return 0;
-	}
-
-	if (current_uid().val != 1000) {
-		// skip non system uid
-		return 0;
-	}
-
-	if (!old_dentry || !new_dentry) {
-		return 0;
-	}
+    // Print the old and new dentry names at the beginning
+    pr_info("Handling rename: old_dentry = %s, new_dentry = %s\n",
+            old_dentry ? old_dentry->d_iname : "NULL",
+            new_dentry ? new_dentry->d_iname : "NULL");
+
+    if (!current->mm) {
+        // Skip kernel threads
+        pr_info("Skipping kernel thread\n");
+        return 0;
+    }
+
+    if (current_uid().val != 1000) {
+        // Skip non-system UID
+        pr_info("Skipping non-system UID: %d\n", current_uid().val);
+        return 0;
+    }
+
+    if (!old_dentry || !new_dentry) {
+        // One of the dentries is NULL
+        pr_info("One or both dentries are NULL\n");
+        return 0;
+    }
 
 	// /data/system/packages.list.tmp -> /data/system/packages.list
-	if (strcmp(new_dentry->d_iname, "packages.list")) {
-		return 0;
-	}
-
-	char path[128];
-	char *buf = dentry_path_raw(new_dentry, path, sizeof(path));
-	if (IS_ERR(buf)) {
-		pr_err("dentry_path_raw failed.\n");
-		return 0;
-	}
-
-	if (strcmp(buf, "/system/packages.list")) {
-		return 0;
-	}
-	pr_info("renameat: %s -> %s, new path: %s\n", old_dentry->d_iname,
-		new_dentry->d_iname, buf);
-
-	track_throne();
-
-	return 0;
+    if (strcmp(new_dentry->d_iname, "packages.list")) {
+        pr_info("New dentry name is not 'packages.list': %s\n", new_dentry->d_iname);
+        return 0;
+    }
+
+    char path[128];
+    char *buf = dentry_path_raw(new_dentry, path, sizeof(path));
+    if (IS_ERR(buf)) {
+        pr_err("dentry_path_raw failed.\n");
+        return 0;
+    }
+
+    // Check if the path is "/system/packages.list"
+    if (strcmp(buf, "/system/packages.list")) {
+        pr_info("Path is not '/system/packages.list': %s\n", buf);
+        return 0;
+    }
+
+    // If all conditions are met, print the rename operation details
+    pr_info("renameat: %s -> %s, new path: %s\n",
+            old_dentry->d_iname, new_dentry->d_iname, buf);
+
+    track_throne();
+
+    return 0;
 }
 
 int ksu_handle_prctl(int option, unsigned long arg2, unsigned long arg3,

The result is that I saw this

It seems like KSU can be able to look at the actual dir instead of just /data/system . On Android-x86 (or here is BlissOS), we prepare the system under /android and then switch_root or chroot to it.

[Remon98]

The same thing happened with LKM in lineage-21.0-20240923-nightly-oriole pixel 6.

[helamonster]

Glad to see this is fixed. Can we get an updated release?

[hmtheboy154]

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

[helamonster]

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

Hmm. I'm using what I thought was the latest build: BlissOS 16.9.7. Am I missing something?

[Zetan9565]

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

Hmm. I'm using what I thought was the latest build: BlissOS 16.9.7. Am I missing something?

I had tried just now, it's still not working on B.OS 16.9.7

[hmtheboy154]

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

Hmm. I'm using what I thought was the latest build: BlissOS 16.9.7. Am I missing something?

Give me the iso name & what show in KSU Manager

[hmtheboy154]

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

Hmm. I'm using what I thought was the latest build: BlissOS 16.9.7. Am I missing something?

I had tried just now, it's still not working on B.OS 16.9.7

you too

[hansalemaos]

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

I tested them yesterday and today and only could get a shell root activating adb shell in kernelsu, and doing this hack in the adb shell

printf "%s\n" 'mount -o remount,rw /' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" 'rm -f /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'echo '\''#!/system/bin/sh'\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c  # or some less permissive chmod 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'printf "%s" '\''exec printf '\''\'\'''\''/data/adb/ksu/bin/busybox sh -c "/system/system_ext/bin/bash" < /dev/tty'\''\'\'''\'' | tr '\''\'\'''\''\n'\''\'\'''\'' '\''\'\'''\''\0'\''\'\'''\'' | toybox xargs -0 -n1 su --preserve-environment --mount-master -c '\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c   # or some less permissive chmod

This gives me a su shell using bashsudo

I hope you get it fixed! I love your project! Really awesome!

[hmtheboy154]

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

I tested them yesterday and today and only could get a shell root activating adb shell in kernelsu, and doing this hack in the adb shell

printf "%s\n" 'mount -o remount,rw /' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" 'rm -f /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'echo '\''#!/system/bin/sh'\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c  # or some less permissive chmod 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'printf "%s" '\''exec printf '\''\'\'''\''/data/adb/ksu/bin/busybox sh -c "/system/system_ext/bin/bash" < /dev/tty'\''\'\'''\'' | tr '\''\'\'''\''\n'\''\'\'''\'' '\''\'\'''\''\0'\''\'\'''\'' | toybox xargs -0 -n1 su --preserve-environment --mount-master -c '\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c   # or some less permissive chmod

This gives me a su shell using bashsudo

I hope you get it fixed! I love your project! Really awesome!

Yea I will have to create a new Github Issue here, I do notice that on Termux I can only get /system/bin/su to working so far.

[hansalemaos]

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

I tested them yesterday and today and only could get a shell root activating adb shell in kernelsu, and doing this hack in the adb shell

printf "%s\n" 'mount -o remount,rw /' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" 'rm -f /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'echo '\''#!/system/bin/sh'\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c  # or some less permissive chmod 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'printf "%s" '\''exec printf '\''\'\'''\''/data/adb/ksu/bin/busybox sh -c "/system/system_ext/bin/bash" < /dev/tty'\''\'\'''\'' | tr '\''\'\'''\''\n'\''\'\'''\'' '\''\'\'''\''\0'\''\'\'''\'' | toybox xargs -0 -n1 su --preserve-environment --mount-master -c '\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c   # or some less permissive chmod

This gives me a su shell using bashsudo I hope you get it fixed! I love your project! Really awesome!

Yea I will have to create a new Github Issue here, I do notice that on Termux I can only get /system/bin/su to working so far.

If I try ksud, su, toybox su, /data/adb/ksu/bin/busybox sh, I don't get anywhere, but using ... toybox xargs -0 -n1 su after piping, piping and more piping it works all of a sudden.

VirtualBox:/ $ whoami
shell
VirtualBox:/ $ printf "%s\n" 'whoami' | tr '\n' '\0' | toybox xargs -0 -n1 su -c
root

VirtualBox:/ $ printf "%s\n" '/system/system_ext/bin/bash < /dev/tty' | tr '\n' '\0' | toybox xargs -0 -n1 su -c
localhost / #

[hansalemaos]

I have just found something else that might help you to solve the problem, but maybe you know it already:

https://github.com/termux-play-store/termux-tools/commit/9187cfa169cc64861a0fc7e98a01b9c78eb1634d#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R7

[hansalemaos]

sudo(){
    printf "%s" "$*" | toybox xargs -0 -n1 su -c 
}

sushell(){
    echo | toybox xargs -0 -n1 su -c '/system/bin/sh < /dev/tty'
}

Here are 2 more user-friendly ways to invoke su, maybe it serves as a temporal workaround for blissOs

[hmtheboy154]

I have just found something else that might help you to solve the problem, but maybe you know it already:

termux-play-store/termux-tools@9187cfa#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R7

I didn't know about this...... interesting though

[hansalemaos]

I have just found something else that might help you to solve the problem, but maybe you know it already: termux-play-store/termux-tools@9187cfa#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R7

I didn't know about this...... interesting though

It may help you. Maybe there is a way to trace how the toybox executable calls: xargs -0 -n1 su -c and then reproducing the syscall somehow.

It seems like through all this piping stuff and toybox, an environment is created where this: execve(2) call in kernel to redirect it to kernel is triggered calling su

[hmtheboy154]

I have just found something else that might help you to solve the problem, but maybe you know it already: termux-play-store/termux-tools@9187cfa#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R7

I didn't know about this...... interesting though

It may help you. Maybe there is a way to trace how the toybox executable calls: xargs -0 -n1 su -c and then reproducing the syscall somehow.

It seems like through all this piping stuff and toybox, an environment is created where this: execve(2) call in kernel to redirect it to kernel is triggered calling su

Made new issue https://github.com/tiann/KernelSU/issues/2113 . If you have any new finding please go there