enhance(Dockerfile): use /etc/resolv.conf and restrict /data permission

[robertkirkman]

• After enhance(main/aosp-libs): improve /system/bin/su, add /system/bin/grep, and connect DNS resolution to resolv-conf termux-packages#30044

• Partially reverts Use dnsmasq as DNS resolver #49

• Handle case of duplicate dependencies between termux-docker packages and termux bootstrap packages

• Document pacman image

• Restrict access to /data and /data/data so that termux-docker can reproduce this issue, and issues very much like it, for termux-docker to be useful for developing a solution to them [Bug]: zsh nocaseglob fails absolute-path extendedglob with '-#' on Termux (minimal repro) termux-packages#28433 . Docker Engine does not seem to allow restricting access to /.

[robertkirkman]

@sylirre I tested and experimented with trying to fully revert

• Use dnsmasq as DNS resolver #49

(by also replacing ENTRYPOINT ["/entrypoint.sh"] with USER 1000:1000 as it was before),

but unfortunately, I found that if I did that, it would make it somewhat more difficult/tedious to correctly use the GitHub Actions container: directive mode with termux-docker, because in that mode, it's necessary to first apply the necessary pid_max limit code for running 32-bit android containers within 64-bit kernels, which on recent kernel versions such as those used within GitHub Actions, thanks to the research and development of thunder-coding, has been found to require running the command to set pid_max as root from within the container (instead of from outside the container as it was in older kernel versions). (for clarity that decision was made by upstream kernel developers and not by thunder-coding)

https://github.com/robertkirkman/termux-on-gha/blob/c3067cdf0a482c07c909ded0e863671e03b1d20d/.github/workflows/build-and-test.yml#L39-L48

that means that if I were to make the default user actually system instead of root, the option --user root would always have to be added to all of the currently existing termux-docker GitHub Actions workflows based on the container: directive, which exist in some places and are relied on by some people, and then those workflows would still need to use the /entrypoint.sh explicitly anyway. I feel like that would counteract the benefits of making the default user system.

[robertkirkman]

There is an obvious sort of solution which is to "root" termux-docker's system user by removing the restriction I have placed/preserved on it to prevent the /system/bin/su command from permitting changing user from the system account to the root account.

However, the reason why I did that originally is because, when I observed the behavior of the original termux-docker before I modified any of termux-docker's code, in 2024, I observed that the original /system/bin/su of termux-docker also did not allow changing user from the system user to the root user.

I interpreted that very literally as "termux-docker is 'unrooted' and is designed to accurately simulate the permissions behavior of an 'unrooted' android device when the system user is logged in".

however, I've never discussed or reconsidered that decision publicly with anyone else. all of that happened inside my head while I was designing the updates to termux-docker, so I don't know if my reasoning makes sense or just sounds insane.

what do you think is a higher priority for the use cases of termux-docker:

to be able to work properly in GitHub Actions container: directive with a little more convenience added by not having to use the /entrypoint.sh explicitly for every non-root command,

or to preserve the original "rootness" of termux-docker such that it's not possible to switch from the system user to the root user after already logging into the system user, without logging out and logging in again?

[robertkirkman]

@tallero @theamericanaccount do you understand this discussion and if so do you have a strong opinion about this decision?

if you still plan to use termux-docker within container: directive within GitHub Actions, this will affect you. if the limitation involving GitHub Actions and pacman in termux-docker #82 prevents you from using it, then you can disregard this thread.