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.

[robertkirkman]

I've decided to keep it as shown in this PR for now and if someone would like the USER 1000:1000 to be used globally again and not only during the build, they can bring it up and options for it can be considered.

[theamericanaccount]

im okay with building in the container as user rather than administrator (if you look at the gnu build section of ur temporary github actions build script youll notice i do the same there already);
i will just have to add a --user root flag somewhere in the CI file am i right?
just in case keep in mind most entrypoint.sh scripts calls are temporary as ideally i would like to run it only once in the ci script (at the very end it will probably just call the ur command once).

i think it may be important though to start assuming termux may not run on android only anymore as it seems really from next year google android will become a computer jail for the world on which only selected developers approved by google will be able to publish applications written for it

i think their intention is to make sure an environment such as the one provided by termux will never really work well on android and will never pose a threat to their monopoly, in such a way i think it could make sense lots of sense to make termux build for a target larger than just aosp in order to prepare all users to deal with the fact google android will soon be dead as apple ios as a computing platform

obviously when i do write 'larger than aosp' i cant but mean dogeos as i dont see any other project having taken on the task of slowly turning aosp itself into a modular, upgradeable, standard, fair os distribution, as projects like lineageos and the others it seems to me they would gladly follow google down a dark pit if they did so and they dont really see themselves as market competitors but rather a niche alternative

in practice it means feel free to propose and implement for dogeos all android changes you see sane in an operating system regardless of what google does because its obvious at this point it just wants free software developers to either starve and never thrive or to eat them alive

in all honesty i cant shrug off me this strong impression there has left only a very very spare amount of sane developers who see where everything is going and are doing something to avoid it, while the crowd has just surrendered to drown in this illiberal hell and condemn all of us to a 1984 nightmare

(development note: dogeos packages list will start growing sensibly when ill have finished writing evm-git so that to upgrade a PKGBUILD to become an universal recipe will be a matter of changing no more than a couple lines in most cases; in another couple of months at max probably all base gnu/linux programs entire sources histories will have been written on-chain)

[robertkirkman]

i think it may be important though to start assuming termux may not run on android only anymore as it seems really from next year google android will become a computer jail

it seems that most people assume that (not only you but also all others), but I have technical knowledge and experience that tells me a different result of the future from everyone else, so I will continue to operate according to my internal predictions.

[robertkirkman]

im okay with building in the container as user rather than administrator (if you look at the gnu build section of ur temporary github actions build script youll notice i do the same there already);

I do not know where in your repo it is, but if you would be OK with adding --user root to the options: section here of all of your .yml files which use container: termux/termux-docker and /entrypoint_root.sh sh -c "echo 65535 | tee /proc/sys/kernel/pid_max",

https://github.com/robertkirkman/termux-on-gha/blob/4ba8290d008ad2f1f95369761f96ad0fd34900d2/.github/workflows/build-and-test.yml#L26

then that would mean it's probably ok with you if I set the default user to system using USER 1000:1000 in the Dockerfile, since you'll be able to undo it for workflows that need /entrypoint_root.sh by applying --user root.