On 06/03/2015 10:17 AM, Redestig, Johan wrote: > For built in commands seclabel obviously is not a factor (I was referencing > rmdir because that is something we usually invoke as an external command > since the internal implementation of it does not make any sense). > > There have recently been a couple of new exec users that explicitly set the > seclabel. It may just become a pattern others follow. I shared the concern of > not unnecessarily specifying the seclabel in the init files, just pointing > out that there are legitimate uses of besides the ramdisk limitation, so > killing it entirely would have other consequences. And from this point of > view exec/service is identical, just difference syntax.
Looking at system/core/rootdir/init.rc, I see these two exec calls: 324: exec u:r:tzdatacheck:s0 system system -- /system/bin/tzdatacheck /system/usr/share/zoneinfo /data/misc/zoneinfo 657: exec - logd log -- /system/bin/logcat -L -b all -v threadtime -v usec -v printable -D -f /data/misc/logd/logcat -r 64 -n 256 Not clear that the first one needs a seclabel or could just use "-" to indicate use of the default since policy defines a transition for tzdatacheck? Second one is already using the - notation to indicate the default. We only need a seclabel if we cannot assign the executable a unique file context that will trigger an automatic domain transition upon exec, as with rootfs binaries or commands that share a common binary but require different domains (e.g. if you wanted to run different toybox/toolbox commands in different domains). I wouldn't suggest removing seclabel support altogether, but we should try to minimize its usage to only the cases where it is truly required. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
