Last update broke superuser script

[Sunil Kumar]

Hi,

I have a script which refers rsync binary from a different package (termux) using the PATH. When I run the script from a shell as root, it works and it was working fine with Automate also. But with latest update to Automate, it says

"/data/data/com.termux/files/usr/bin/rsync: inaccessible or not found"

Anybody know what changed in recent versions to trigger this and how I can fix it?

Thanks

[Henrik "The Developer" Lindqvist]

The Automate "File" blocks should never have been able to access /data/data.

Since Android 10 binary executable are not allowed, see: https://www.reddit.com/r/androiddev/comments/b2inbu/psa_android_q_blocks_executing_binaries_in_your/

[Bushmills]

In case you have Magisk installed, there's a module "SSH for Magisk" which provides ssh, sshd and rsync.

Installed to /system/xbin. As bonus you can opt to launch a key authenticated ssh during boot, allowing

ssh logon to mobile device from remote anytime, no preparations needed.

rsync and ssh on mobile can naturally key-authenticate too.

[Sunil Kumar]

Henrik,

But this was working fine in 1.26, and I have another phone with 1.26 where it works with latest Android 11 (LOS18.1). How do we explain that?

Once you run something as root, I would have thought /data/data access is allowed.

Thanks

[Henrik "The Developer" Lindqvist]

Automate version 1.32 now "targets" Android 11, an Google Play Store requirement, that indeed affect all file access.

But, as said, /data/data should never be accessible by the File blocks or otherwise since it's on internal/private storage.

The Shell command superuser block may been to, e.g. using ls, cp, mv, etc.

How is the flow accessing /data/data/com.termux/files/usr/bin/rsync, with which block?

[Leo 12]

Hi, I can't create a question, so I'll write here. A friend gave me a script, but it won't open for me, even though I'm using the latest version, including being a beta tester. Shows this window 

вторник, 8 марта 2022 г. в 04:12:19 UTC+3, Henrik "The Developer" Lindqvist:

[Henrik "The Developer" Lindqvist]

Somehow the flow file must have been corrupted, as the maximum version is currently only at 93.

[Leo 12]

I'm shocked, can this be fixed? 

вторник, 8 марта 2022 г. в 17:31:17 UTC+3, Henrik "The Developer" Lindqvist:

[Henrik "The Developer" Lindqvist]

Tell the friend to send it to you again, preferably in some other way, e.g. through Google Drive, or by uploading it to the community.

[Sunil Kumar]

It is a super user shell command block. If you run a script as superuser, isn't the script being run as root?

So, if I run 'sh +x /sdcard/backup.sh' from root shell in 'adb' or same from automate's super user shell, it should work the same. All the programs that backup.sh calls should be running as root and have no access issues.

Is that not the case anymore? What changed from 1.26 to 1.32 that makes the above not true any more?

[Henrik "The Developer" Lindqvist]

The Shell command superuser block should indeed run the command line as the root user, if your su binary (rooting app) is configured correctly, test by executing: id

[Sunil Kumar]

In the termux shell and in adb shell, 'su' gives me id of 0 (root). I am not sure what happens inside the automate's execution of 'su'. I am assuming it gets an effective ID of 0.

The script runs fine when run from a root termux shell and a root adb shell.

Thanks

[Henrik "The Developer" Lindqvist]

Try executing the id command with the Shell command superuser block and log its Standard out text.

Termux being able to access its own files is expected, and an root adb shell as well,

but a third-party app/process like Automate maybe restricted by some SELinux context policy.

[Sunil Kumar]

I did that the output shows uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0

Thanks

[Sunil Kumar]

Just to be completely clear: the output is EXACTLY same, including the context.

Thanks

[Henrik "The Developer" Lindqvist]

As said, then it must be some SELinux context policy interfering, or the Android 10+ restriction on executable in /data/data, see: https://www.reddit.com/r/androiddev/comments/b2inbu/psa_android_q_blocks_executing_binaries_in_your/

If you're using Magisk, try asking their forum: https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/

[Sunil Kumar]

But what changed from 1.26 to 1.32 in automate which broke this? 1.26 still works with latest Android 11.

Thanks

[Henrik "The Developer" Lindqvist]

As said, version 1.32+ "target" Android 11, i don't know how that affects Magisk.

[Pete]

Stumbled on the fix today after some deep diving...

"As @alecxs said, these apps does not handle correctly mounting namespaces, and therefore we need to select in Magisk settings Mount Namespace Mode->Global Namespace instead of Inherit"

https://android.stackexchange.com/questions/245735/cannot-list-all-folders-in-data-data-in-few-apps

[Pete]

More info on the subject....

https://www.reddit.com/r/androiddev/comments/hk3hrq/were_on_the_android_engineering_team_ask_us/fwqxb4b/

https://x.com/topjohnwu/status/1279508461370269696

"By default Magisk inherits the calling process's mount namespace. This can be changed in Magisk Manager. If your root app always need global mount access, use --mount-master when calling su. This can be easily done in libsu by adding a flag in config."