On 01/11/2015 11:25 AM, Daniel Doron wrote: > BTW, FYI, I did try using the binder as recommended. > I followed this example: > http://www.androidenea.com/2010/03/share-memory-using-ashmem-and-binder-in.html#comment-form_903870610350693814 > > but I am hitting again a wall because : > > E/SELinux ( 172): avc: denied { add } for > service=android.vendor.IEneaBuffer scontext=u:r:surfaceflinger:s0 > tcontext=u:object_r:default_android_service:s0 tclass=service_manager > E/ServiceManager( 172): add_service('android.vendor.IEneaBuffer',7) > uid=1000 - PERMISSION DENIED > > apparently, according to domain.te policy: > > # *Do not allow service_manager add for default_android_service.* > # Instead domains should use a more specific type such as > # system_app_service rather than the generic type. > # New service_types are defined in service.te and new mappings > # from service name to service_type are defined in service_contexts. > *neverallow domain default_android_service:service_manager add;*
As Bill said, you need to assign your service a more specific type than the default. If your service should be treated identically to any other surfaceflinger service, then you could just assign your service name the existing u:object_r:surfaceflinger_service:s0 security context in the service_contexts file. If your service should be distinguished with respect to who can look it up from other surfaceflinger services, then you could define a new service type in service.te and then assign it via service_contexts. Regardless, do this in your device-specific policy via BOARD_SEPOLICY* variables rather than modifying the external/sepolicy files directly. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
