On Friday, 4 December 2015, 18:00, William Roberts <[email protected]> 
wrote:


>
>
>
>
>
>
>On Thu, Dec 3, 2015 at 3:04 AM, Richard Haines 
><[email protected]> wrote:
>
>
>>On Thursday, 3 December 2015, 10:07, Elena Reshetova 
>><[email protected]> wrote:
>>
>>
>>>
>>>
>>>Hi guys,
>>>
>>>I have been investigating a really weird issue and want to ask if you know 
>>>what might go wrong.
>>>So, normally file_contexts file is composed from the 
>>>external/sepolicy/file_contexts and OEM modifications that can be declared 
>>>in different places in file_contexts files, but joined using the 
>>>BOARD_SEPOLICY_DIRS. For example:
>>>BOARD_SEPOLICY_DIRS += device/intel/sepolicy/bla/xyz
>>>
>>>All is good and it worked for ages, but now it works strangely on one (and 
>>>only one) particular addition in file_contexts like this:
>>>
>>>/dev/xyz           u:object_r:xyz_device:s0
>>>
>>>
>>
>>>Important part here is that there is no newline at the end of the above line 
>>>(which is quite normal and the same for many other similar file_contexts 
>>>file).
>>
>>
>>I fixed a problem of this type in libselinux with the change at:
>>
>>https://android-review.googlesource.com/#/c/157661/
>>in June as part of the Enhanced spec file support. Could you check if this is 
>>present,
>>if so I'll investigate further.
>>>
>>
>
>
>Now that I am not on a mobile device and can open these files up in a proper 
>hex editor I can also see what the problem is (which is exactly as described). 
>No 0x0A at the end of the files... Looking through the AOSP file_contexts 
>files, they all do indeed end with 0x0A, I was just expecting the webpage to 
>show the newline, but it shows it in more vim style and requires a newline + 
>other character to show the next line. As additional check, I looked for any 
>DOS endings in our policy, and nothing crept in there.
>
>
>However, that patch to pull in, would require its dependencies to be pulled in 
>as well:
>
>
>external/libselinux$ !888
>git shortlog --all -- src/label_file.h
>Jeffrey Vander Stoep (1):
>      Revert "libselinux: Enhance spec file support"
>
>
>Richard Haines (3):
>      libselinux: Enhance spec file support
>      libselinux: Enhance spec file support
>      Fix mmap memory release for file labeling
>
>
>Stephen Smalley (1):
>      libselinux: fail hard on invalid file_contexts entries
>
>
>William Roberts (1):
>      fix memory leaks and uninitialized jump
>
>

>
My preferred solution is to add something like the following
to external/sepolicy/README:

Additional, per device, policy files can be added into the
policy build. "These files MUST have each line including the
final line terminated by a newline character (0x0A).  This
will allow files to be concatenated and processed whenever
the m4(1) macro processor is called by the build process."

Note that there is an exception in that the last line of the
last file processed may exclude the newline (as some files
under "device" are currently built this way).


After various tests when building AOSP master:
1) For multiple file_contexts as per Elena's issue the problem will
be caught by checkfc.

2) Property and service contexts files will also be caught by checkfc.

3) Policy files do not seem to suffer this problem, as from my tests
checkpolicy is quite happy with multiple statements/comments
on a single line as it just looks for delimiters.

4) The multiple seapp_contexts and mac_permissions.xml do not suffer
from this problem as they are processed by check_seapp/insertkeys.py
that looks for delimiters and strips comments.>
> 
>>
>>>So, what happens is that line gets added to the resulted file_contexts there 
>>>is a no newline after and the next addition to file_contexts get written to 
>>>the same line (straight after the label). So, in the resulting file_contexts 
>>>we have:
>>>
>>>/dev/xyz           u:object_r:xyz_device:s0#Additional file_contexts
>>>
>>>
>>>Where "#Additional file_contexts"  is the first line  of another 
>>>file_contexts file that happens to be added after.
>>>
>>>
>>>Of course selinux has an issue with the above label, so it complains:
>>>
>>>out/target/product/bla/root/file_contexts: line 721 has invalid file type 
>>>u:object_r:xyz_device:s0#
>>>out/target/product/bla/root/file_contexts: line 721 has invalid file type 
>>>u:object_r:xyz_device:s0#
>>>out/target/product/bla/root/file_contexts: line 721 has invalid file type 
>>>u:object_r:xyz_device:s0#
>>>out/target/product/bla/root/file_contexts: line 721 has invalid file type 
>>>u:object_r:xyz_device:s0#
>>>
>>>
>>>
>>>Any ideas why this happens?
>>>
>>>
>>>Best Regards,
>>>
>>>Elena.
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>Seandroid-list mailing list
>>>[email protected]
>>>To unsubscribe, send email to [email protected].
>>>To get help, send an email containing "help" to 
>>>[email protected].
>>>
>>>
>>_______________________________________________
>>Seandroid-list mailing list
>>[email protected]
>>To unsubscribe, send email to [email protected].
>>To get help, send an email containing "help" to 
>>[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].

Reply via email to