>Was the other statement accurate? It failed with the addition of an fc
entry or was it always failing and just not manifesting as a problem until
now?

I don't know if it was visible previously in any logs ever, but as you know
we have a lot of separated file_contexts files and most of them don't have
any newlines at the end.
Despite that they all work and when I see the resulted file_contexts file,
is it correct. Issue started to be visible only for this particular case.

On Thu, 3 Dec 2015 at 16:43 William Roberts <[email protected]>
wrote:

> Elena,
>
> Was the other statement accurate? It failed with the addition of an fc
> entry or was it always failing and just not manifesting as a problem until
> now?
>
> On Thu, Dec 3, 2015, 9:31 AM William Roberts <[email protected]>
> wrote:
>
>> Oh it didn't fail hard. Definitely want that commit.
>>
>> On Thu, Dec 3, 2015, 9:29 AM Elena Reshetova <[email protected]>
>> wrote:
>>
>>> The thing is that we don't have a build error, build was completed
>>> successfully, but we started to see issues in run-time when a node label
>>> was default and not the one specified.
>>> We actually do not have the commit pointed by Stephen in our tree, which
>>> is first thing to fix
>>>
>>>
>>> On Thu, 3 Dec 2015 at 16:20 William Roberts <[email protected]>
>>> wrote:
>>>
>>>> I don't think the question is why it fails. I think we all agree the
>>>> snippet posted by Elena should fail. But what I still don't understand is
>>>> why the addition of a entry to an fc without a newline causes the build
>>>> error to finally manifest.
>>>>
>>>> We should also update all the device policies so they have a newline in
>>>> AOSP so the examples are correct.
>>>>
>>>> On Thu, Dec 3, 2015, 9:15 AM Stephen Smalley <[email protected]> wrote:
>>>>
>>>>> On 12/03/2015 09:02 AM, Stephen Smalley wrote:
>>>>> > On 12/03/2015 05:07 AM, Elena Reshetova 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).
>>>>> >>
>>>>> >> 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?
>>>>> >
>>>>> > I don't see why this would ever work (I just tried with 5.1.1 and it
>>>>> > failed there too).  m4 (or cat) doesn't insert newlines automatically
>>>>> > between input files, so if you do not newline-terminate your files,
>>>>> they
>>>>> > will get munged in this way.
>>>>>
>>>>> Oh, I see - this didn't become a hard error at build time until:
>>>>> https://android-review.googlesource.com/#/c/163570
>>>>>
>>>>> But it is wrong regardless and will cause that line to get ignored at
>>>>> runtime.
>>>>>
>>>> _______________________________________________
>>>>> 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].

Reply via email to