On Wed, Apr 15, 2009 at 7:25 AM, Jean-Baptiste Queru <j...@android.com>wrote:
> The user-space runtime itself enforces some of the permissions (e.g. > the broad permissions on content providers and broadcast receivers). > Finer-grained permissions can be enforced by asking the Binder to > check a permission on an IPC initiator. Actually all permissions checks either boil down to a check based on uid after an IPC, or a filesystem-based gid as mentioned below. For example, content provider permissions are checked by the activity manager when it receives an incoming IPC from an application requesting a content provider (to determine if it has access at all), and by the content provider itself when receiving an incoming IPC from another process to perform read/write permission checks. This directly implies that permissions can only be enforced at the granularity of the process level (and actually they are only done at the uid level). We also extensively rely on the Binder's capability model (unless someone explicitly gives you an IBinder object, you have no access to it) as a mechanism for enforcing security/isolation in many places. > Some permissions are tied to unix GIDs, and some (like the INTERNET > one) are enforced by the kernel. I believe that that latter two > categories are set by the forked zygote while it specializes itself > into an app process. Yes, when zygote is asked to fork a process, the activity manager gives it an array of additional gids to grant it, based on the permisssions granted to the application. In /system/etc/permissions are files that map from permission names to gid for the ones that are needed. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
