Installing 1Panel Using Docker on TrueNAS Background My TrueNAS has some performance headroom, so I'm thinking of deploying a web service. I want to install a control panel to reduce manual work. Considering the performance overhead of virtual machines, the high memory requirements for ZFS cache, and the fact that the NAS itself isn't very powerful, I decided to use Docker for deployment. Furthermore, since 1Panel itself is distributed as a Docker image, both systems controlling the TrueNAS host's Docker daemon is essentially equivalent to deploying websites directly on the TrueNAS host, making management easier. Analysis {alert type="warning"} This article assumes TrueNAS can access Docker Hub and the Docker daemon is already configured. {/alert} Environment Information Storage Pool There are two storage pools: /mnt/data: 1 x MIRROR | 2 wide | 2.73 TiB | HDD /mnt/systemdata: 1 x DISK | 1 wide | 223.57 GiB | SSD Docker data is stored in storage pool #2. Datasets There are three datasets: Storage: Located in the data storage pool, stores cold data. DockerData: Located in the systemdata storage pool, stores persistent data for containers. KaguraiYoRoy: Located in systemdata, the user's home directory. Installing 1Panel Used the moelin/1panel:latest image for deployment. Many parts of this process can refer to the README written by the image author. Project address: okxlin/docker-1panel Created a folder specifically for storing 1Panel data within the DockerData dataset, which is used as /opt/1panel inside the container, located at /mnt/systemdata/DockerData/1panel. Persistent Volumes To allow 1Panel to manage the host's Docker, map /var/run/docker.sock and the host's Docker directory. Map the data folder created for it earlier. The Docker directory in TrueNAS is different from typical Linux systems. Typically, it's at /var/lib/docker, but in TrueNAS, it's at /mnt/.ix-apps/docker. Environment Variables and Port Mapping The environment variables are the same as those set by the image author, passing TZ=Asia/Shanghai. Port mapping can be set as needed; the container's port is 10086. Docker Compose With the above information, writing the Docker Compose file becomes straightforward. The complete Docker Compose file is as follows: services: 1panel: dns: - 223.5.5.5 environment: - TZ=Asia/Shanghai image: moelin/1panel:latest labels: createdBy: Apps ports: - '8085:10086' restart: always volumes: - /var/run/docker.sock:/var/run/docker.sock - /mnt/.ix-apps/docker:/var/lib/docker - /mnt/systemdata/DockerData/1panel/opt:/opt/1panel - /mnt/systemdata/DockerData/1panel/root:/root - /etc/docker:/etc/docker Mapping /root is because I need to run Git inside the container, and Git config is stored under /root. Setting DNS is because 1Panel needs to download data online when building environment images, and errors occur without specifying DNS. After installation, access the port you set. 1Panel Basic Information: Default Username: 1panel Default Password: 1panel_password Default Entrance: entrance Troubleshooting Docker Mirror During testing, it was found that without setting a mirror source, even with a Proxy configured, installing the PHP environment would fail. Furthermore, configuring both a mirror source and a Proxy also led to installation failure; the reason is unclear. Open /etc/docker/daemon.json on TrueNAS and add registry-mirrors: { "data-root": "/mnt/.ix-apps/docker", "default-address-pools": [ { "base": "172.17.0.0/12", "size": 24 } ], "exec-opts": [ "native.cgroupdriver=cgroupfs" ], "iptables": true, "registry-mirrors": [ "https://docker.1panel.live" ], "storage-driver": "overlay2" } Save the file, restart the host's Docker service, then try installing the environment in 1Panel again. {alert type="warning"} This configuration might be lost after a reboot. Try to install all necessary environments and apps in one go if possible. {/alert} Containers Created by 1Panel Fail to Start This is because in 1Panel, the default folder for storing data is the mapped /opt/1panel. However, the containers actually run on the TrueNAS host and try to access /opt/1panel, which doesn't exist on TrueNAS by default, and its /opt is read-only by default. This causes a "Read-only filesystem" error when starting containers. My solution is straightforward: On the TrueNAS host, first remount /opt as read-write, then create a symbolic link pointing to 1Panel's data folder. cd /opt mount -o remount,rw /opt ln -s /mnt/systemdata/DockerData/1panel/opt 1panel After this, it should work normally. One thing to note: When installing OpenResty in 1Panel, remember to avoid using ports 80 and 443, as these are the default ports for the TrueNAS web UI.

Using Infrared Camera for Face Recognition on Xiaomi 845 Series with Custom ROMs Background The Xiaomi 845 series, specifically the Mi 8 and Mi 8 Pro (UDFPS), feature a dedicated front-facing infrared camera for facial recognition. This enables facial unlock functionality even in complete darkness. However, when using a custom ROM like LineageOS compiled from its standard device tree, the infrared camera remains inaccessible, forcing the system to rely on the standard front camera. Interestingly, PixelExperience ROMs successfully utilize this hardware. This article explores the reasons behind this discrepancy and outlines the solution. The Cause CameraID The first step is directing the face recognition module to use the infrared camera. Examining the PixelExperience device tree source code reveals an overlay that configures the face unlock service to use the camera with ID 5. https://github.com/PixelExperience-Devices/device_xiaomi_dipper/blob/fourteen/overlay/packages/apps/FaceUnlockService/app/src/main/res/values/config.xml <?xml version="1.0" encoding="utf-8"?> <resources> <integer name="override_front_cam_id">5</integer> <bool name="use_alternative_vendor_impl">true</bool> </resources> PixelExperience uses Motorola's face unlock solution. Many other custom ROMs, however, utilize AOSPA's ParanoidSense. Therefore, the PixelExperience overlay method isn't directly applicable. Inspecting the ParanoidSense source code shows that it uses a system property, ro.face.sense_service.camera_id, to identify which camera to use. https://github.com/AOSPA/android_packages_apps_ParanoidSense/blob/uvite/src/co/aospa/sense/camera/CameraUtil.kt#L32 val cameraIdProp = SystemProperties.get("ro.face.sense_service.camera_id") Thus, in theory, simply setting the ro.face.sense_service.camera_id property to 5 should direct it to the infrared camera. The vendor.camera.aux.packagelist Property Merely setting the CameraID property is insufficient; the face unlock module would simply fail to access the camera. Delving into the Android framework code reveals that the system, by default, hides auxiliary cameras (AuxCameras) beyond the primary front and rear cameras. The infrared camera falls into this AuxCamera category. Using LineageOS framework code as an example: https://github.com/LineageOS/android_frameworks_base/blob/lineage-21.0/core/java/android/hardware/Camera.java#L295-L301 /** * Returns the number of physical cameras available on this device. * The return value of this method might change dynamically if the device * supports external cameras and an external camera is connected or * disconnected. * * If there is a * {@link android.hardware.camera2.CameraCharacteristics#REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA * logical multi-camera} in the system, to maintain app backward compatibility, this method will * only expose one camera per facing for all logical camera and physical camera groups. * Use camera2 API to see all cameras. * * @return total number of accessible camera devices, or 0 if there are no * cameras or an error was encountered enumerating them. */ public static int getNumberOfCameras() { int numberOfCameras = _getNumberOfCameras(); if (!shouldExposeAuxCamera() && numberOfCameras > 2) { numberOfCameras = 2; } return numberOfCameras; } As shown, even if a device has more than two cameras, if the shouldExposeAuxCamera() function returns False, the system reports only two cameras, preventing access to any camera with an ID greater than 1. Let's examine this function: https://github.com/LineageOS/android_frameworks_base/blob/lineage-21.0/core/java/android/hardware/Camera.java#L264-L278 /** * @hide */ public static boolean shouldExposeAuxCamera() { /** * Force to expose only two cameras * if the package name does not falls in this bucket */ String packageName = ActivityThread.currentOpPackageName(); if (packageName == null) return true; List<String> packageList = Arrays.asList( SystemProperties.get("vendor.camera.aux.packagelist", packageName).split(",")); List<String> packageExcludelist = Arrays.asList( SystemProperties.get("vendor.camera.aux.packageexcludelist", "").split(",")); return packageList.contains(packageName) && !packageExcludelist.contains(packageName); } The logic is clear: if the current application's package name is listed in the vendor.camera.aux.packagelist system property and is not in the vendor.camera.aux.packageexcludelist property, the function returns True, allowing access to auxiliary cameras. The solution becomes evident: add the ParanoidSense package name (co.aospa.sense) to the vendor.camera.aux.packagelist property. The Solution Add the ParanoidSense package name co.aospa.sense to the vendor.camera.aux.packagelist property: https://github.com/YoriInstitute/crDroidAndroid_device_xiaomi_sdm845-common/commit/28fe5bc41d49b31b4acb840bf167b70d70a40c61 Set the ro.face.sense_service.camera_id property to specify the correct camera ID: https://github.com/YoriInstitute/crDroidAndroid_device_xiaomi_equuleus/commit/67518f130650e4592b5f4c7210248072058d48cc https://github.com/YoriInstitute/AOSPA_device_xiaomi_equuleus/blob/topaz/device.mk#L397-L399 In the crDroid-modified version of ParanoidSense, which is placed in the system_ext partition (refer: https://gitlab.com/crdroidandroid/android_packages_apps_FaceUnlock/-/commit/545688260eb32ba19f348e84e3cae89ba29f20d1), this property should be added to the corresponding system_ext prop file.

Brief Understanding of Some Files and Concepts in AOSP Device Trees {alert type="warning"} The following content largely represents my personal understanding of some concepts within device trees and is not official definitions. Corrections are welcome if any errors are found. {/alert} The common contents of a device tree can be broadly categorized as follows: Android.bp Various Makefiles, with the suffix .mk prop files, with the suffix .prop overlay, placed in the overlay folder sepolicy, i.e., SELinux rules, placed in the sepolicy folder manifest.xml and FCM (framework_compatibility_matrix.xml) extract-files.py, setup-makefiles.py, and proprietary-files.txt Dependency files ending with .dependencies Various other configurations Android.bp This is the configuration file for the AOSP build system, Ninja. The device tree doesn't rely heavily on it (main content is usually in Android.mk and other Makefiles). It's generally used to introduce other soong_namespaces, allowing references to Modules from other directories. Let's take the LineageOS socrates device tree as an example: // // Copyright (C) 2024 The LineageOS Project // // SPDX-License-Identifier: Apache-2.0 // soong_namespace { imports: [ "hardware/xiaomi", ], } Here, it declares the import of the namespace from hardware/xiaomi, enabling PRODUCT_PACKAGES to reference items from hardware/xiaomi. Makefile Android.mk This file defines the entry point for the entire device tree (it should be). Again, using socrates as an example: # # Copyright (C) 2024 The LineageOS Project # # SPDX-License-Identifier: Apache-2.0 # LOCAL_PATH := $(call my-dir) ifeq ($(TARGET_DEVICE),socrates) include $(LOCAL_PATH)/vendor-symlinks.mk include $(call all-subdir-makefiles,$(LOCAL_PATH)) include $(CLEAR_VARS) # A/B builds require us to create the mount points at compile time. # Just creating it for all cases since it does not hurt. FIRMWARE_MOUNT_POINT := $(TARGET_OUT_VENDOR)/firmware_mnt $(FIRMWARE_MOUNT_POINT): $(LOCAL_INSTALLED_MODULE) @echo "Creating $(FIRMWARE_MOUNT_POINT)" @mkdir -p $(TARGET_OUT_VENDOR)/firmware_mnt BT_FIRMWARE_MOUNT_POINT := $(TARGET_OUT_VENDOR)/bt_firmware $(BT_FIRMWARE_MOUNT_POINT): $(LOCAL_INSTALLED_MODULE) @echo "Creating $(BT_FIRMWARE_MOUNT_POINT)" @mkdir -p $(TARGET_OUT_VENDOR)/bt_firmware DSP_MOUNT_POINT := $(TARGET_OUT_VENDOR)/dsp $(DSP_MOUNT_POINT): $(LOCAL_INSTALLED_MODULE) @echo "Creating $(DSP_MOUNT_POINT)" @mkdir -p $(TARGET_OUT_VENDOR)/dsp ALL_DEFAULT_INSTALLED_MODULES += $(FIRMWARE_MOUNT_POINT) $(BT_FIRMWARE_MOUNT_POINT) $(DSP_MOUNT_POINT) endif It shows that if TARGET_DEVICE equals socrates, the build system will proceed to include all Makefiles in this directory and define some mount points here. AndroidProduct.mk This file is typically used to include the os_codename.mk file below and define COMMON_LUNCH_CHOICES. It defines the types supported by the device during lunch (generally distinguishing between user, userdebug, and eng builds). Note: COMMON_LUNCH_CHOICES seems to have been removed in Android 14 and above builds. BoardConfig.mk {alert type="info"} In common trees (if they exist), this is often named BoardConfigCommon.mk {/alert} As the name suggests, this is the board configuration file for the phone. It generally defines things like CPU architecture, partition sizes, kernel parameters, etc. It usually includes the SEPolicy folder, various prop files, manifest.xml, FCM, and other hardware-related parameters. Most configurations here are generally reusable across different ROMs. device.mk {alert type="info"} In common trees (if they exist), this is often named soc.mk or common.mk. For example, it's named sdm845.mk in Xiaomi's sdm845-common and lito.mk in Xiaomi's sm7250-common. {/alert} This file generally defines services within the Android operating system, includes various libraries, copies permission files (e.g., LineageOS/android_device_xiaomi_sdm845-common/blob/lineage-22.1/sdm845.mk#L26-L62). Some of the content here is reusable across different ROMs; please decide based on the specific situation. os_codename.mk This file typically defines content highly specific to the current ROM. For example, using socrates: # # Copyright (C) 2024 The LineageOS Project # # SPDX-License-Identifier: Apache-2.0 # # Inherit common AOSP configurations $(call inherit-product, build/make/target/product/full_base_telephony.mk) $(call inherit-product, build/make/target/product/core_64_bit_only.mk) # Inherit device-specific configurations $(call inherit-product, device/xiaomi/socrates/device.mk) # Inherit LineageOS configurations $(call inherit-product, vendor/lineage/config/common_full_phone.mk) PRODUCT_NAME := lineage_socrates PRODUCT_DEVICE := socrates PRODUCT_MODEL := Redmi K60 Pro PRODUCT_BRAND := Redmi PRODUCT_MANUFACTURER := Xiaomi BUILD_FINGERPRINT := Redmi/socrates/socrates:14/UKQ1.230804.001/V816.0.11.0.UMKCNXM:user/release-keys It includes necessary configurations for the build and LineageOS configurations. Referencing different configuration files here can set the operating system bitness and distinguish between tablet and phone. For instance, including build/make/target/product/core_64_bit_only.mk means the ROM built from this device tree only supports 64-bit apps. If core_64_bit.mk were included instead, it would also support 32-bit apps. Including vendor/lineage/config/common_full_phone.mk indicates adaptation for a phone-type device. For a tablet-type device, common_full_tablet.mk or common_full_tablet_wifionly.mk would be included. The section below defines device-related information like manufacturer, brand, device codename, and model. Prop Files These define Property attributes within the system, functioning similarly to prop files inside the system. They define entries required by software that relies on props for settings. It's recommended to refer to online introductions for details, as we won't elaborate much here. Overlay Official introduction: Android Overlay is a resource replacement mechanism that allows replacing resource files without repackaging the APK (res directory, not assets directory). Personal understanding: Used to replace and override specific content in the res XML of specified software within the system, allowing modifications to system settings, toggles, etc. For example: https://github.com/LineageOS/android_device_xiaomi_socrates/blob/lineage-22.1/overlay/SystemUIOverlaySocrates/res/values/config.xml#L24 {collapse} {collapse-item label="Expand Code"} <?xml version="1.0" encoding="utf-8"?> <!-- /* ** Copyright 2009, The Android Open Source Project ** ** Licensed under the Apache License, Version 2.0 (the "License"); ** you may not use this file except in compliance with the License. ** You may obtain a copy of the License at ** ** http://www.apache.org/licenses/LICENSE-2.0 ** ** Unless required by applicable law or agreed to in writing, software ** distributed under the License is distributed on an "AS IS" BASIS, ** WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. ** See the License for the specific language governing permissions and ** limitations under the License. */ --> <!-- These resources are around just to allow their values to be customized for different hardware and product builds. --> <resources> <!-- Doze: does this device support STATE_DOZE? --> <bool name="doze_display_state_supported">true</bool><!--这一行--> <!-- Color of the UDFPS pressed view --> <color name="config_udfpsColor">#00FFFFFF</color> <!-- paddings for container with status icons and battery --> <dimen name="status_bar_icons_padding_start">0dp</dimen> <dimen name="status_bar_icons_padding_end">0dp</dimen> <!-- the padding on the start of the statusbar --> <dimen name="status_bar_padding_start">10dp</dimen> <!-- the padding on the end of the statusbar --> <dimen name="status_bar_padding_end">4dp</dimen> </resources> {/collapse-item} {/collapse} This modifies the variable of the same name here: https://github.com/LineageOS/android_frameworks_base/blob/lineage-22.1/packages/SystemUI/res/values/config.xml#L175 and thereby indicates whether the device supports Doze display:https://github.com/LineageOS/android_frameworks_base/blob/472a48741ac22537b3a0d1c0b87dbff2c1c2af8f/packages/SystemUI/src/com/android/systemui/statusbar/phone/DozeParameters.java#L185-L187 When writing overlays, one generally needs to reference the definitions of items in the res within the system and replace their values as needed. .dependencies Files As the name implies, dependencies. This file defines which dependent repositories are needed to use this device tree, encoded in JSON. The basic format is as follows: [ { "repository": "", "target_path": "", "branch": "", "remote": "" }, { "repository": "", "target_path": "", "branch": "", "remote": "" } ] Parameter details: remote: The remote address, corresponding to the remote address in the main source tree's manifest. This parameter is optional. If not specified, it defaults to cloning from the default remote address in the main source tree's manifest. repository: The repository address, i.e., this repository under the remote address. Required. branch: The branch corresponding to the branch used when downloading from the specified repository. Optional. If not specified, it defaults to the same branch as the main source tree. target_path: The clone target path. Required. clone-path: The clone depth, similar to the --depth parameter in the git clone command. Optional. If not specified, it defaults to a full download (same logic as the git command). revision: Can be understood as the branch. Optional. Therefore, a simplest dependencies file without the optional parameters can look like this: https://github.com/LineageOS/android_device_xiaomi_equuleus/blob/lineage-22.1/lineage.dependencies [ { "repository": "android_device_xiaomi_sdm845-common", "target_path": "device/xiaomi/sdm845-common" } ] When using commands like breakfast that automatically download supported device trees, this file is used to integrate the required repositories into the main source tree's manifest and download them together. extract-files.py, setup-makefiles.py, and proprietary-files.txt These files are used when generating the Vendor tree. Generally, the required blobs are listed in proprietary-files.txt, then extract-files.py is run to extract blobs from the system or a dump and create the vendor tree. That's all for now, more may be added later.

Migrating RR Loader for Synology DSM I wrote this article because the original disk was a 16GB USB drive, and the target disk is a 16GB Optane. Although both are 16GB, the original one is slightly larger (I don't know why either orz). Directly using dd won't work since the source disk is larger than the target, so I'm documenting the process here. {alert type="warning"} Data is priceless, tinkering requires caution. {/alert} Analysis The RR boot disk has three partitions: FAT32,50.00MB Ext2,50.00MB Ext4,occupying the remaining space The first partition is the boot partition and is bootable (marked with an asterisk under "Boot" in fdisk -l). The second partition's purpose is unclear, but it's likely for GRUB. The third partition holds Synology's kernel and RR Loader configuration files. Approach Since the first two partitions are small, we can use dd to copy them entirely to the target disk. For the third partition, we'll manually create and format it, then synchronize the UUID and Label. {alert type="warning"} This process uses Linux operations. {/alert} Let's Start Connect both disks to the system: source disk as /dev/sda, target disk as /dev/sdb. Check the source disk information: sudo fdisk -l /dev/sda Output: Disk /dev/sda: 14.55 GiB, 15627976704 bytes, 30523392 sectors Disk model: Storage Media Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x66d0fe82 Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 104447 102400 50M 83 Linux /dev/sda2 104448 206847 102400 50M 83 Linux /dev/sda3 206848 30523391 30316544 14.5G 83 Linux Copy the First Two Partitions and Disk Partition Table to the Target Disk sudo dd if=/dev/sda of=dev/sdb count=206848 # Note: The count value here is the start of the third partition above. Adjust according to your disk. Output: 206848+0 records in 206848+0 records out 105906176 bytes (106 MB, 101 MiB) copied, 11.3812 s, 9.3 MB/s Create the Third Partition Open the disk with fdisk: sudo fdisk /dev/sdb First, wipe the existing third partition data: Type d, and when prompted with Partition number (1-3, default 3):, enter 3 or just press Enter. After seeing Partition 3 has been deleted., type n to create a new partition. Select primary partition by typing p, and accept the default options for the rest by pressing Enter. Once done, type w to save and exit. If you're unfamiliar with fdisk, search for tutorials online. Format the Newly Created Partition and Write UUID and Label sudo mkfs.ext4 /dev/sdb3 Check the details of the source disk's third partition using the file command: sudo file -s /dev/sda3 Output: /dev/sda3: Linux rev 1.0 ext4 filesystem data, UUID=617a3aca-4b56-42d7-8558-54411b344a7d, volume name "RR3" (extents) (64bit) (large files) (huge files) Note down the UUID and volume name (i.e., "RR3"), and use the following commands to write them to the new disk: sudo tune2fs /dev/sdb3 -U df39b1f3-b846-49dc-a317-ce329ec87ca2 # Write UUID sudo tune2fs /dev/sdb3 -L RR3 # Write volume name Copy data Mount the third partitions of both disks. Assume the source is mounted at ~/a and the target at ~/b. Then, copy all data from a to b (this step is straightforward with cp, so no detailed explanation needed). Finally, unmount all mount points, disconnect the disks, and connect them to your NAS. The migration should be successful.

Adding KernelSU Support to Android 4.9 Kernel Introduction KernelSU has been available for a while. Officially, it only supports GKI kernels, but the project provides integration guidelines for non-GKI kernels. The Xiaomi Mi 8 Pro, which I use, is based on the Android 4.9 kernel. Testing showed that directly using KernelSU's integration script caused issues, so I'm documenting the process here. Special thanks to: Developer Tomsec for providing the 4.9 kernel fix. Prerequisites Android Kernel source code. Here, we use LineageOS/android_kernel_xiaomi_sdm845 Network access to GitHub AnyKernel3 source code. You can refer to this repository: YoriInstitute/AnyKernel3-equuleus Cross-compiler. You can refer to this repository: https://github.com/YoriInstitute/AnyKernel3-equuleus/blob/13/.github/workflows/build.yml#L21-L23 A build server Let's Start Configuring the build environment won't be detailed here. You can integrate it directly into the boot.img when building the ROM, or compile it separately as an AnyKernel3 flashable zip. This guide uses the AnyKernel3 approach. Download Kernel Source Code and Cross-Compiler git clone https://github.com/KaguraiYoRoy/android_kernel_xiaomi_sdm845 -b lineage-20 sdm845 #Kernel source git clone https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86 --depth=1 -b android-13.0.0_r43 clang #Clang git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9 -b android-10.0.0_r32 --depth=1 #aarch64 GCC git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9 -b android-10.0.0_r32 --depth=1 #arm GCC Different kernels might require different cross-compilers. Please adjust according to your specific case. {alert type="info"} When cloning the kernel source, --depth=1 wasn't used initially to facilitate easier cherry-picking later. If you plan to manually modify the kernel source instead of using cherry-pick, you can add this parameter to significantly reduce download time. {/alert} Modify Kernel Source Refer to the following two commits: https://github.com/OnlyTomInSecond/android_kernel_xiaomi_sdm845/commit/7862fd2c14b69a1a346b7c699f8370e2de423eef commit b5853fb7cefdc8a2e160cb73512dc6b51569fa66 Author: OnlyTomInSecond <[email protected]> Date: Wed Apr 5 11:05:12 2023 +0800 kernelsu: allow init exec ksud under nosuid Change-Id: I8aa6e6d3cbee1addd5da9bb48b4c08ce91f9db81 diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 4abba0e1674d..693f2ac03352 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2320,7 +2320,10 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm, { int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS); int nosuid = !mnt_may_suid(bprm->file->f_path.mnt); - int rc; + int rc, error; + static u32 ksu_sid; + char *secdata; + u32 seclen; if (!nnp && !nosuid) return 0; /* neither NNP nor nosuid */ @@ -2328,6 +2331,18 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm, if (new_tsec->sid == old_tsec->sid) return 0; /* No change in credentials */ + if(!ksu_sid){ + security_secctx_to_secid("u:r:su:s0", strlen("u:r:su:s0"), &ksu_sid); + } + error = security_secid_to_secctx(old_tsec->sid, &secdata, &seclen); + if (!error) { + rc = strcmp("u:r:init:s0",secdata); + security_release_secctx(secdata, seclen); + if(rc == 0 && new_tsec->sid == ksu_sid){ + return 0; + } + } + /* * The only transitions we permit under NNP or nosuid * are transitions to bounded SIDs, i.e. SIDs that are https://github.com/OnlyTomInSecond/android_kernel_xiaomi_sdm845/commit/81d7168f2f01e6aba0932a4787119fbc541eba58 commit 8bfe4d4de25650505798cba0a5a20db4b2ab7dd6 Author: OnlyTomInSecond <[email protected]> Date: Thu Oct 19 17:55:23 2023 +0800 Kernelsu: add path_umount implementation. Change-Id: I3b0273e9857c51cc3215afab0d2cebe0dff38cfb diff --git a/fs/namespace.c b/fs/namespace.c index 21fd423b19cf..219a501337b0 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -1711,6 +1711,38 @@ static inline bool may_mandlock(void) } #endif +static int can_umount(const struct path *path, int flags) +{ + struct mount *mnt = real_mount(path->mnt); + + if (!may_mount()) + return -EPERM; + if (path->dentry != path->mnt->mnt_root) + return -EINVAL; + if (!check_mnt(mnt)) + return -EINVAL; + if (mnt->mnt.mnt_flags & MNT_LOCKED) /* Check optimistically */ + return -EINVAL; + if (flags & MNT_FORCE && !capable(CAP_SYS_ADMIN)) + return -EPERM; + return 0; +} + +// caller is responsible for flags being sane +int path_umount(struct path *path, int flags) +{ + struct mount *mnt = real_mount(path->mnt); + int ret; + + ret = can_umount(path, flags); + if (!ret) + ret = do_umount(mnt, flags); + + /* we mustn't call path_put() as that would clear mnt_expiry_mark */ + dput(path->dentry); + mntput_no_expire(mnt); + return ret; +} /* * Now umount can handle mount points as well as block devices. * This is important for filesystems which use unnamed block devices. Solution Source: Tomsec Enable KPROBE Support Open your kernel's defconfig file and add the following three lines: CONFIG_KPROBES=y CONFIG_HAVE_KPROBES=y CONFIG_KPROBE_EVENTS=y Integrate KernelSU This step is the same as the official ksu guide. Execute the following command in the kernel root directory: curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5 {alert type="warning"} Note: The highest version of KernelSU supporting non-GKI kernels is v0.9.5. Do not use a higher version tag, or the build will fail. {/alert} Write the AnyKernel3 Script Download AnyKernel3 and modify anykernel.sh according to the README. You can refer to my repository for modifications: Repository: https://github.com/iYoRoy-AOSP-Institute/AnyKernel3-equuleus/blob/14/anykernel.sh {collapse} {collapse-item label="Expand Code"} commit 3b46e03e0ffdd52bbb3f51b45b0ff649a407d1a5 Author: KaguraiYoRoy <[email protected]> Date: Sat Sep 9 02:41:54 2023 +0000 anykernel.sh: modify for equuleus diff --git a/anykernel.sh b/anykernel.sh old mode 100755 new mode 100644 index 367d29f..c950ce7 --- a/anykernel.sh +++ b/anykernel.sh @@ -4,23 +4,17 @@ ### AnyKernel setup # global properties properties() { ' -kernel.string=ExampleKernel by osm0sis @ xda-developers +kernel.string=Xiaomi 8 Pro Kernel by Kagura iYoRoy @ iYoRoy Studio do.devicecheck=1 do.modules=0 -do.systemless=1 +do.systemless=0 do.cleanup=1 do.cleanuponabort=0 -device.name1=maguro -device.name2=toro -device.name3=toroplus -device.name4=tuna -device.name5= -supported.versions= +device.name1=equuleus +supported.versions=13 supported.patchlevels= -supported.vendorpatchlevels= '; } # end properties - ### AnyKernel install ## boot files attributes boot_attributes() { @@ -29,7 +23,7 @@ set_perm_recursive 0 0 750 750 $ramdisk/init* $ramdisk/sbin; } # end attributes # boot shell variables -block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot; +block=/dev/block/bootdevice/by-name/boot; is_slot_device=0; ramdisk_compression=auto; patch_vbmeta_flag=auto; @@ -41,32 +35,26 @@ patch_vbmeta_flag=auto; dump_boot; # use split_boot to skip ramdisk unpack, e.g. for devices with init_boot ramdisk # init.rc -backup_file init.rc; -replace_string init.rc "cpuctl cpu,timer_slack" "mount cgroup none /dev/cpuctl cpu" "mount cgroup none /dev/cpuctl cpu,timer_slack"; +#backup_file init.rc; +#replace_string init.rc "cpuctl cpu,timer_slack" "mount cgroup none /dev/cpuctl cpu" "mount cgroup none /dev/cpuctl cpu,timer_slack"; # init.tuna.rc -backup_file init.tuna.rc; -insert_line init.tuna.rc "nodiratime barrier=0" after "mount_all /fstab.tuna" "\tmount ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data remount nosuid nodev noatime nodiratime barrier=0"; -append_file init.tuna.rc "bootscript" init.tuna; +#backup_file init.tuna.rc; +#insert_line init.tuna.rc "nodiratime barrier=0" after "mount_all /fstab.tuna" "\tmount ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data remount nosuid nodev noatime nodiratime barrier=0"; +#append_file init.tuna.rc "bootscript" init.tuna; # fstab.tuna -backup_file fstab.tuna; -patch_fstab fstab.tuna /system ext4 options "noatime,barrier=1" "noatime,nodiratime,barrier=0"; -patch_fstab fstab.tuna /cache ext4 options "barrier=1" "barrier=0,nomblk_io_submit"; -patch_fstab fstab.tuna /data ext4 options "data=ordered" "nomblk_io_submit,data=writeback"; -append_file fstab.tuna "usbdisk" fstab; +#backup_file fstab.tuna; +#patch_fstab fstab.tuna /system ext4 options "noatime,barrier=1" "noatime,nodiratime,barrier=0"; +#patch_fstab fstab.tuna /cache ext4 options "barrier=1" "barrier=0,nomblk_io_submit"; +#patch_fstab fstab.tuna /data ext4 options "data=ordered" "nomblk_io_submit,data=writeback"; +#append_file fstab.tuna "usbdisk" fstab; write_boot; # use flash_boot to skip ramdisk repack, e.g. for devices with init_boot ramdisk ## end boot install -## init_boot files attributes -#init_boot_attributes() { -#set_perm_recursive 0 0 755 644 $ramdisk/*; -#set_perm_recursive 0 0 750 750 $ramdisk/init* $ramdisk/sbin; -#} # end attributes - -# init_boot shell variables +## init_boot shell variables #block=init_boot; #is_slot_device=1; #ramdisk_compression=auto; @@ -98,13 +86,7 @@ write_boot; # use flash_boot to skip ramdisk repack, e.g. for devices with init_ ## end vendor_kernel_boot install -## vendor_boot files attributes -#vendor_boot_attributes() { -#set_perm_recursive 0 0 755 644 $ramdisk/*; -#set_perm_recursive 0 0 750 750 $ramdisk/init* $ramdisk/sbin; -#} # end attributes - -# vendor_boot shell variables +## vendor_boot shell variables #block=vendor_boot; #is_slot_device=1; #ramdisk_compression=auto; @@ -118,4 +100,3 @@ write_boot; # use flash_boot to skip ramdisk repack, e.g. for devices with init_ #write_boot; # use flash_boot to skip ramdisk repack, e.g. for dtb on devices with hdr v4 but no vendor_kernel_boot ## end vendor_boot install - {/collapse-item} {/collapse} Compile the Kernel It's recommended to refer to online tutorials for this step, as compilation parameter settings can vary for different kernels. I've packaged the compilation process into a shell script for reference: {alert type="info"} Please replace $WORKSPACE below with your own working directory. {/alert} #!/bin/bash ARCH="arm64" CLANG_DIR="$WORKSPACE/clang/clang-r450784d" #Clang directory CC="$CLANG_DIR/bin/clang" export PATH="$CLANG_DIR/bin:$PATH" OUT_DIR="./out" CLANG_TRIPLE="aarch64-linux-gnu-" CROSS_COMPILE="$WORKSPACE/aarch64-linux-android-4.9/bin/aarch64-linux-androidkernel-" #aarch64 GCC CROSS_COMPILE_ARM32="$WORKSPACE/arm-linux-androideabi-4.9/bin/arm-linux-androidkernel-" #arm GCC CC_ADDITION_FLAGS="AR=llvm-ar NM=llvm-nm OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump STRIP=llvm-strip LLVM_IAS=1 LLVM=1 LD=ld.lld" ANYKERNEL_DIR="$WORKSPACE/AnyKernel3" #Location of your prepared AnyKernel3 directory THREAD=$(nproc --all) args="-j$THREAD O=$OUT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE CROSS_COMPILE_ARM32=$CROSS_COMPILE_ARM32 CC=$CC CLANG_TRIPLE=$CLANG_TRIPLE $CC_ADDITION_FLAGS" ### Compile Kernel ### echo "[+]Args: $args" echo "[+}Generate .config" make equuleus_user_defconfig $args #Here 'equuleus_user_defconfig' is the defconfig file for the equuleus kernel. Replace it with your kernel's config file name. echo "[+]Begin Build" make $args ### Compilation Complete ### ### Create AnyKernel3 Zip ### cd $WORKSPACE/sdm845/KernelSU KSU_VERSION='v0.9.5' TARGET_KERNEL="Mi8Pro-LineageKernel-KernelSU$KSU_VERSION" #Kernel filename echo "[+]KernelSU Version: $KSU_VERSION" echo "[+]Target file: $TARGET_KERNEL" cd $WORKSPACE/AnyKernel3 cp $WORKSPACE/sdm845/out/arch/arm64/boot/Image . cp $WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz . cp $WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz-dtb . OUTPUT_FILE=${TARGET_KERNEL}-$(date +"%y.%m.%d").zip echo "[+]Output: $OUTPUT_FILE" zip -r $OUTPUT_FILE * mv $OUTPUT_FILE $WORKSPACE Flashing Use a recovery like TWRP to flash the zip. Automatically Compile the Kernel using GitHub Actions Refer to this YAML file for workflow setup: https://github.com/iYoRoy-AOSP-Institute/AnyKernel3-equuleus/blob/13/.github/workflows/build.yml {collapse} {collapse-item label="Expand Code"} name: Build AnyKernel on: push: schedule: - cron: '0 0 * * 0' jobs: build: runs-on: ubuntu-latest steps: - name: Download run: | echo "Free space:" df -h cd $GITHUB_WORKSPACE echo "[+]Install packages:" sudo apt update sudo apt install zip bc bison build-essential ccache curl flex g++-multilib gcc-multilib git gnupg gperf imagemagick lib32ncurses5-dev lib32readline-dev lib32z1-dev liblz4-tool libncurses5-dev libncurses5 libsdl1.2-dev libssl-dev libwxgtk3.0-gtk3-dev libxml2 libxml2-utils lzop pngcrush rsync schedtool squashfs-tools xsltproc zip zlib1g-dev make unzip python-is-python3 echo "[+]Clone dependencies:" git clone https://github.com/KaguraiYoRoy/android_kernel_xiaomi_sdm845 -b lineage-20 sdm845 git clone https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86 --depth=1 -b android-13.0.0_r43 clang git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9 -b android-10.0.0_r32 --depth=1 git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9 -b android-10.0.0_r32 --depth=1 git clone https://github.com/KaguraiYoRoy/AnyKernel3-equuleus AnyKernel3 --depth=1 - name: Setup KernelSU run: | cd $GITHUB_WORKSPACE/sdm845 curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main - name: Build Kernel run: | cd $GITHUB_WORKSPACE/sdm845 ARCH="arm64" CLANG_DIR="$GITHUB_WORKSPACE/clang/clang-r450784d" CC="$CLANG_DIR/bin/clang" export PATH="$CLANG_DIR/bin:$PATH" OUT_DIR="./out" CLANG_TRIPLE="aarch64-linux-gnu-" CROSS_COMPILE="$GITHUB_WORKSPACE/aarch64-linux-android-4.9/bin/aarch64-linux-androidkernel-" CROSS_COMPILE_ARM32="$GITHUB_WORKSPACE/arm-linux-androideabi-4.9/bin/arm-linux-androidkernel-" CC_ADDITION_FLAGS="AR=llvm-ar NM=llvm-nm OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump STRIP=llvm-strip LLVM_IAS=1 LLVM=1 LD=ld.lld" THREAD=$(nproc --all) ANYKERNEL_DIR="$GITHUB_WORKSPACE/AnyKernel3" args="-j$THREAD O=$OUT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE CROSS_COMPILE_ARM32=$CROSS_COMPILE_ARM32 CC=$CC CLANG_TRIPLE=$CLANG_TRIPLE $CC_ADDITION_FLAGS" echo "[+]Args: $args" echo "[+}Generate .config" make equuleus_user_defconfig $args echo "[+]Begin Build" make $args - name: Compress run: | cd $GITHUB_WORKSPACE/sdm845/KernelSU KSU_VERSION=`expr 10000 + \`git rev-list --count HEAD\` + 200` TARGET_KERNEL="Mi8Pro-LineageKernel-KernelSU$KSU_VERSION" echo "[+]KernelSU Version: $KSU_VERSION" echo "[+]Target file: $TARGET_KERNEL" cd $GITHUB_WORKSPACE/AnyKernel3 cp $GITHUB_WORKSPACE/sdm845/out/arch/arm64/boot/Image . cp $GITHUB_WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz . cp $GITHUB_WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz-dtb . OUTPUT_FILE=${TARGET_KERNEL}-$(date +"%y.%m.%d").zip echo "[+]Output: $OUTPUT_FILE" zip -r $OUTPUT_FILE * mv $OUTPUT_FILE $GITHUB_WORKSPACE - name: Release uses: softprops/action-gh-release@v1 with: tag_name: Android13 files: | Mi8Pro*.zip I definitely won't tell you that the script above was also extracted from here x {/collapse-item} {/collapse}