On production —
user build of a ROM — you can't start
adbd as root unless ROM or at least
adbd binary is rebuilt with required modifications. Reason is the
ALLOW_ADBD_ROOT build flag (1, 2).
That's why adbd Insecure was developed, which replaced the
adbd binary with a modified one.
eng build (or with insecure
adbd binary extracted from any of these build types):
adbd runs as root when enabled from Settings (Developer Options) (3). However
adb root won't work (4).
adb root will restart
adbd as root (5, 6).
adbd can be built from modified source code to skip all these checks. Additionally SELinux should also be taken care of, if in
adbd must be allowed to run in unrestricted superuser context:
u:r:su:s0 (7, 8), which isn't the case for
user builds (9, 10, 11). See this answer for more details.
Android properties can be overwritten using
eng builds i.e. if
ALLOW_LOCAL_PROP_OVERRIDE build flag is set (12, 13). But this doesn't work for
ro.* properties (14) and same is true for
setprop commandline tool. However
prop.default file — which could be located under multiple possible locations depending on the device build configurations (15) — can be modified to change read-only properties (if not already set from some other property file or
*.rc file). If the file is in ramdisk,
boot.img needs to be modified.
Magisk's resetprop tool can reset the read-only properties even if they are already set.
ro.debuggable both may have possibly been changed as a part of MagiskHide policy (16), which you can revert back to allow
adbd run as root.
Another related property is
ro.adb.secure, which controls public key authentification. By setting
eng builds, authentification is skipped (no
device unauthorized message ever) (17, 18, 19); related: Storage location of “adb_keys”.
adb rootdoesn't work on "production builds" (like stock ROMs, even if rooted). So unless you have a "developer ROM", chances this does anything are quite low.