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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
