We have lots of tools that we run only on userdebug and eng builds and are now being forced to write (ugly) policy for tools we never intend to ship (my company restricts making changes to AOSP projects so changing this internally isn’t as simple as it could be).
Would you be open to a patch that sets this variable with ?= so that board files can override? Any chance this change, marked prominently with “DO NOT MERGE”, was not actually intended to be merged and can be reverted? Thanks! Russell From: Elena Reshetova [mailto:[email protected]] Sent: Wednesday, February 18, 2015 10:34 AM To: William Roberts Cc: seandroid-list; Webb, Russell Subject: Re: Question about FORCE_PERMISSIVE_TO_UNCONFINED in Android.mk > So permissive domains are allowed on everything BUT user builds, but if you > wanted to make permissive domains unconfined for some reason, notably to > silence the logs, you can override FORCE_PERMISSIVE_TO_UNCONFINED Yes, this makes sense and this is the desired behaviour. Just the commit 2aa727e3f01f814384bd4a49281c7c 39cf562ff6 was very confusing. Best Regards, Elena. On Wed, Feb 18, 2015 at 10:23 AM, William Roberts <[email protected]<mailto:[email protected]>> wrote: On Wed, Feb 18, 2015 at 10:10 AM, Elena Reshetova <[email protected]<mailto:[email protected]>> wrote: Hi, In Android.mk under sepolicy/external, there is a definition that seems illogical to us: FORCE_PERMISSIVE_TO_UNCONFINED:=true ifeq ($(TARGET_BUILD_VARIANT),user) # User builds are always forced unconfined+enforcing FORCE_PERMISSIVE_TO_UNCONFINED:=true endif Would it be instead better to have it this way: FORCE_PERMISSIVE_TO_UNCONFINED:=true ifeq ($(TARGET_BUILD_VARIANT),userdebug) # Userdebug builds are not forced to unconfined+enforcing FORCE_PERMISSIVE_TO_UNCONFINED:=false endif It would allow userdebug builds to have permissive domains, which greatly helps if you need to run some special debug/logging utilities and don't want to waste time on creating policies for them. Opinions? The most up-to-date in Android.mk is as follows: # Force permissive domains to be unconfined+enforcing? # # During development, this should be set to false. # Permissive means permissive. # # When we're close to a release and SELinux new policy development # is frozen, we should flip this to true. This forces any currently # permissive domains into unconfined+enforcing. # FORCE_PERMISSIVE_TO_UNCONFINED ?= false ifeq ($(TARGET_BUILD_VARIANT),user) # User builds are always forced unconfined+enforcing FORCE_PERMISSIVE_TO_UNCONFINED := true endif So permissive domains are allowed on everything BUT user builds, but if you wanted to make permissive domains unconfined for some reason, notably to silence the logs, you can override FORCE_PERMISSIVE_TO_UNCONFINED This then gets pased to m4 as a macro definition in the Android.mk as: -D force_permissive_to_unconfined=$(FORCE_PERMISSIVE_TO_UNCONFINED) \ Which later is expanded in te_macros: ##################################### # permissive_or_unconfined # Returns "permissive $1" if FORCE_PERMISSIVE_TO_UNCONFINED is false, # and "unconfined($1)" otherwise. # # This is used for experimental domains, where we want to ensure # the domain is unconfined+enforcing once new SELinux policy development # has ceased. # define(`permissive_or_unconfined', ifelse(force_permissive_to_unconfined, `false', permissive $1;, unconfined_domain($1))) So if you want domains to follow this, make sure to use permissive_or_unconfined macro on that domain type. Best Regards, Elena. _______________________________________________ Seandroid-list mailing list [email protected]<mailto:[email protected]> To unsubscribe, send email to [email protected]<mailto:[email protected]>. To get help, send an email containing "help" to [email protected]<mailto:[email protected]>. -- Respectfully, William C Roberts
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
