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