Сторонний рут не монтирует, adb root может.

если у тебя userdebug - зачем тебе всякий мусор в виде

Рутом от магиска или phh-su

?

su, whoami

ну и getenforce на всякий покажи, под рутом

whoami везде root я сравнивал руты от магиск и адб в /proc/self и там есть много различиий

selinux отключается, это точо, но мб не полностью?

Магиск модули не монтирует, зигиск не пашет без костыля. Я сейчас через termux так с помощью adb root монтирую и убиваю surfaceflinger, чтоб был такой вот софт ребут, при котором зигота перезапустится, а монтирования останутся. Тогда зигиск работает.

sudo setprop service.adb.root 1 sudo setprop service.adb.tcp.port 5555 sudo stop adbd sudo start adbd adb wait-for-device adb shell whoami adb shell mount /sbin/.magisk/zygisk/app_process32 /system/bin/app_process32 adb shell mount /sbin/.magisk/zygisk/app_process64 /system/bin/app_process64 echo soft reboot sleep 5 sudo kill $(sudo pidof surfaceflinger)

Хочу быть белым человеком с нормально работающим магиском. Мб отключить selinux в ядре, чтоб он точно не работал или security_sb_mount и такое прочее в ядре пропатчить…

вот часть кода do_mount, думаю весь затык в security_sb_mount

retval = security_sb_mount(dev_name, &path, type_page, flags, data_page); if (!retval && !may_mount()) retval = -EPERM;

я не знаю что такое magisk и подбный крап. еще раз говорю, в юзердебаг прошивке su уже есть! ты можешь стартануть adb (без adb root), там сделать su, whoami, getenforce?

пс. setenforce 0 может сделать кстати только процесс, запущенный под su selinux доменом.

selinux отключается, это точо, но мб не полностью?

он не может не полностью отключаться. если noperm маунта связан с selinux - ты увидишь эту ругань в dmesg или в logcat.

$ whoami shell $ getenforce Permissive

dmesg ничего не показывает в logcat только

07-04 11:41:18.729 0 0 I : [07-04 11:41:18] do_mount pid:18283 comm:mount mount /dev/block/dm-0 at ///, flags:2129956

whoami shell $ getenforce Permissive

su то сделай перед whoami

phhgsi_arm64_ab:/ $ whoami
shell
phhgsi_arm64_ab:/ $ su –version
24.3:MAGISKSU
phhgsi_arm64_ab:/ $ su
phhgsi_arm64_ab:/ # whoami
root
phhgsi_arm64_ab:/ # getenforce
Permissive
phhgsi_arm64_ab:/ # remount
failed to remount partition dev:/dev/block/dm-0 mnt:/: Operation not permitted
failed to remount partition dev:/dev/block/dm-1 mnt:/vendor: Operation not permitted
skip unmounted partition dev:/dev/block/dm-3 mnt:/vgc: Operation not permitted
failed to remount partition dev:/dev/block/bootdevice/by-name/dsp mnt:/vendor/dsp: Operation not permitted remount failed

mount -o remount,rw /

?

а вижу, выше так и вызывал

phhgsi_arm64_ab:/ $ su –version 24.3:MAGISKSU

я все равно не понимаю, зачем. в userdebug сборке уже идет свой su.

adb root не делает ничего необычного, инит его просто рестартует под рутом.

remount аналогичен mount -o rw,remount

Ну вот хочется, чтоб все без костылей работало и без userdebug

вот /proc/self/attr/current для разных рутов phh-su u:r:phhsu_daemon:s0

magisk u:r:magisk:s0

adb root u:r:su:s0

Я же могу выполнить от всех рутов mount -o ro,remount / Значит где-то должна быть проверка флагов. По коду ядра(не моего телефона) все сводится к call_int_hook, а за это ведь у меня selinux должен отвечать?

если ошибка с доступом связана с selinux - это может быть из за домена. у тебя выше видно, что только adb привязан к selinux домену su. но в permissive режиме это не должно ролять.

Я же могу выполнить от всех рутов mount -o ro,remount

а ты уверен, что он вообще что то делает на remount ro, когда раздел и так в ro? посмотри стрейсом, мне кажется там сисколл mount вообще не вызывается в этом случае.

Ну вот хочется, чтоб все без костылей работало и без userdebug

в user режиме с включенным selinux все ОЧЕНЬ сложно. как я говорил выше, в userdebug существует домен su, под ним запускается adb root, su. в его описании есть такой макрос.

[viper@viper-manjaro sepolicy]$ cat public/su.te 
# All types must be defined regardless of build variant to ensure
# policy compilation succeeds with userdebug/user combination at boot
type su, domain;

# File types must be defined for file_contexts.
type su_exec, exec_type, file_type;

userdebug_or_eng(`
  # Domain used for su processes, as well as for adbd and adb shell
  # after performing an adb root command.  The domain definition is
  # wrapped to ensure that it does not exist at all on -user builds.

т.е в user сборках никакого su (я про домен, бинаря тоже нет разумеется) нет. ни один процесс (даже если он под рутом) не сможет сделать setenforce 0. т.е, если у тебя задача перемонтировать разделы в такой сборке - тебе нужно искать уязвимость в сервисе, у которого есть доступ к монтированию, например vold, init, etc.

почему у тебя сейчас это не работает - я не понимаю, но грешу на selinux и говеные рутовые тулы. верни родной su, проверь его домен, протестируй.

короч я бы с strace начал.

перемонтировал через adb root, далее команды от magisk рута

mount | grep " / "

/dev/block/dm-0 on / type ext4 (rw,seclabel,nodev,relatime,discard)

mount -o ro,remount /

:/ # mount | grep " / "

/dev/block/dm-0 on / type ext4 (ro,seclabel,nodev,relatime,discard)

вот этот ответ похож на нужное https://unix.stackexchange.com/a/233694

в юзердебаг прошивке su уже есть!

nowai

О чем я и говорю - ты переписал оригинальный su, потерял его капабилити. Если в них проблема конечно.

Прожуй, потом говори

пересобрал магиск 24.3 с контекстом su, теперь $id uid=0(root) gid=0(root) groups=0(root) context=u:r:su:s0

но не монтирует

короче, ядро защищает логические разделы system,vendor,oem,копаться в нем лен без знаний

написал .rc скрипт для магиска, он его внедряет в init.rc, соответственно монтирует не магиск

on zygote-start exec u:r:su:s0 – /system/bin/mount /sbin/.magisk/zygisk/app_process32 /system/bin/app_process32 exec u:r:su:s0 – /system/bin/mount /sbin/.magisk/zygisk/app_process64 /system/bin/app_process64

также в init.rc можно смонтировать overlayfs поверх system и vendor, а дальше уже работать с верхним слоем через magisk-su

что-то код поехал, но итак понятно