Bug#769961: hard-coded UIDs and GIDs
There is probably something that could be probed. For example, all Android devices must be running 'zygote' since that's what starts all the other processes. .hc signature.asc Description: OpenPGP digital signature
Bug#769961: hard-coded UIDs and GIDs
intrigeri: Hans-Christoph Steiner wrote (12 Dec 2014 12:32:59 GMT) : First of all, please don't break threads. Sorry, I don't understand what you mean by this. I think that Ivo meant that your previous email (54874ee7.9020...@eds.org) was a reply to his (20141119190826.ga19...@ugent.be), but was lacking References and In-Reply-To headers. Sorry. I blame Thunderbird for this... .hc signature.asc Description: OpenPGP digital signature
Bug#769961: hard-coded UIDs and GIDs
On Fri, Dec 12, 2014 at 01:32:59PM +0100, Hans-Christoph Steiner wrote: Right now, the package is only installable on systems that do not have the linux-image meta-package installed and are very likely to in a chroot. So that eliminates the majority of Debian installs as candidates where this package is installable. Ideally there would be a way to actually detect the Android kernel, I have not found that way. I wonder if you could probe for either ashmem or binder? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#769961: hard-coded UIDs and GIDs
Hans-Christoph Steiner wrote (12 Dec 2014 12:32:59 GMT) : First of all, please don't break threads. Sorry, I don't understand what you mean by this. I think that Ivo meant that your previous email (54874ee7.9020...@eds.org) was a reply to his (20141119190826.ga19...@ugent.be), but was lacking References and In-Reply-To headers. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85fvcjpzb2@boum.org
Bug#769961: hard-coded UIDs and GIDs
I hope you do not mean to dismiss the problems that I outlined, they are real, and this package as in solves them. So we are talking about a scenario where the perfect is the enemy in the good. The existing package has problems, but also solves real problems. You outlined two real problems: * this package should only be installable on systems running an Android kernel * changing user/group UIDs/GIDs without changing the file system permissions can cause bad things to happen. Right now, the package is only installable on systems that do not have the linux-image meta-package installed and are very likely to in a chroot. So that eliminates the majority of Debian installs as candidates where this package is installable. Ideally there would be a way to actually detect the Android kernel, I have not found that way. About changing UIDs and GIDs, this package could just do a search and replace the UIDs and GIDs of affected files. Having debootstrap install this package earlier in the process sounds good to me, but I know little about that stuff, and the cdebootstrap developer does not seem to be keen on including stuff that is outside of the core mission of the debian installer. First of all, please don't break threads. Sorry, I don't understand what you mean by this. .hc signature.asc Description: OpenPGP digital signature
Bug#769961: hard-coded UIDs and GIDs
Hi, First of all, please don't break threads. On Tue, Dec 09, 2014 at 08:35:03PM +0100, Hans-Christoph Steiner wrote: I think you don't understand the situation with the Android kernel. I think I do. There are hard-coded UIDs and GIDs in the kernel itself that represent the Android permissions, and special Android processes. When running Debian on top of an Android kernel, those UIDs and GIDs cannot be changed. I understand that. So not changing the UID/GID stuff in Debian is actually the risky thing to do. I disagree. The problem is that android-permissions can be installed on existing systems (not running on android) as well. Blindly changing uid/gid there is a very bad thing to do. Even on systems running in a chroot on android, this shouldn't be changed as a result of installing a package. For example, by default, the first user account that Debian creates is UID 1000. That is the GID of the Android 'system' permission, granting wide ranging permissions to the system. I doubt anyone wants to grant the first user such permissions, both automatically and unchangeably. I guess you will agree that blindly changing the uid of an existing user can never be a good thing to do. If this uid needs to be changed, the admin of the system needs to be aware of this, and probably clean up afterwards. Another example is that if the Debian 'audio' GID does not match Android 'audio' GID, the Debian 'audio' group will never be able to grant permissions to use the audio devices. As for installing android-permissions with debootstrap, that's how this package is used. And it turns out that there are system groups already created by the time debootstrap installs android-permissions. That is why I made that change. Is there a way to avoid this, by having debootstrap install android-permissions earlier in the boot process? Having the groups created with a certain hardcoded id (the one used by the android kernel) is one thing. Changing it on the fly is something else. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141210171128.ga13...@ugent.be
Bug#769961: hard-coded UIDs and GIDs
Hey Ivo, I think you don't understand the situation with the Android kernel. There are hard-coded UIDs and GIDs in the kernel itself that represent the Android permissions, and special Android processes. When running Debian on top of an Android kernel, those UIDs and GIDs cannot be changed. So not changing the UID/GID stuff in Debian is actually the risky thing to do. For example, by default, the first user account that Debian creates is UID 1000. That is the GID of the Android 'system' permission, granting wide ranging permissions to the system. I doubt anyone wants to grant the first user such permissions, both automatically and unchangeably. Another example is that if the Debian 'audio' GID does not match Android 'audio' GID, the Debian 'audio' group will never be able to grant permissions to use the audio devices. As for installing android-permissions with debootstrap, that's how this package is used. And it turns out that there are system groups already created by the time debootstrap installs android-permissions. That is why I made that change. .hc signature.asc Description: OpenPGP digital signature
