> I've tested various ways to simulate this but failed to get your results. > It always fails during the initial build when sefcontext_compile > builds the binary file_contexts file (that always validates the contexts). >
I think this is because we don't have the patch that Stephen pointed out. So, for us build doesn't fail, but the issue shows up later. So, if you have this patch, you won't be able to reproduce at all. > > FYI - If context files or entries end with '\r', then getline(3) reads them > as one continuous line as it expects '\n' so this could be your problem. > How it gets past the build I don't know. > > Please feel free to send me your files and I'll test some more. > I am attaching two files. file_contexts_1 is the one that added first and file_contexts_2 is the one that is added straight after it to cause the issue. > On Thursday, 3 December 2015, 14:51, Elena Reshetova < > [email protected]> wrote: > > > > > > > >>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]. > > > > >
file_contexts_1
Description: Binary data
file_contexts_2
Description: Binary data
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
