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].
