After open the SELINUX, boot process log is as follows:
1467283596.977: [48.530560] type=1400 audit (209) : avc: denied {write} for pid=6360 comm="droid. Launcher3" name="card0" dev="TMPFS" ino=10259 scontext=u: r: untrusted_app: s0: c512, c768 tcontext=ubject_r: device: s0 tclass=chr_file permissive=0
1467283597.020: [48.573350] type=1400 audit (210) : avc: denied {write} for pid=6313 comm="ndroid. Systemui" name="card0" dev="TMPFS" ino=10259 scontext=u: r: platform_app: s0: c512, c768 tcontext=ubject_r: device: s0 tclass=chr_file permissive=0
1467283597.020: [48.594576] type=1400 audit (211) : avc: denied {write} for pid=6380 comm="RenderThread" name="card0" dev="TMPFS" ino=10259 scontext=u: r: untrusted_app: s0: c512, c768 tcontext=ubject_r: device: s0 tclass=chr_file permissive=0
1467283597.189: [48.742435] type=1400 audit (212) : avc: denied {write} for pid=6386 comm="RenderThread" name="card0" dev="TMPFS" ino=10259 scontext=u: r: platform_app: s0: c512, c768 tcontext=ubject_r: device: s0 tclass=chr_file permissive=0

From the above log analysis, should give untrusted_app a write permissions.
So I'm on the external/sepolicy untrusted_app. Te added in the following:
Allow untrusted_app device: chr_file write;

Then rewoven verification, and report the error. Other selinxu errors have not appeared, just this sentence.

Analysis, found the log above the
Scontext=u: r: untrusted_app: s0: c512, c768
Above this sentence have different place,
General selinux error, scontext is composed of four parts, the last part is s0, but here I have c512, after the log c768
Feeling has something to do with this.

Warrior knows how to return a responsibility?
Thank you thank you very much.

CodePudding user response:

Your problem solved

CodePudding user response:

Looking forward to solution together

CodePudding user response:

This problem solved?? I also encountered similar problems, please guide, thank you

CodePudding user response:

I met this problem solved, the reason is caused by changes in the security context security level in the scontext, solution with restorecon - R were changed the directory (documents),

CodePudding user response:

Look at what to write file's security context is

CodePudding user response:

Do I have to solve? Meet the same problem with you

CodePudding user response:

http://blog.csdn.net/lushengchu_luis/article/details/52775740 the same problem effective measurement

CodePudding user response:

Please comment finally how to solve?

CodePudding user response:

Likely is the problem that user permissions, you in other devices without selinux permissions to delete this directory, manually create again, try,

CodePudding user response:

Solve the building Lord, I have encountered the same problem, very urgent

CodePudding user response:

This involves selinux multiple access control (MLS)
/system/sepolicy/MLS has control over chr_file file, you can have a look at first.

CodePudding user response:

Have a relationship, you will have to stay in the file. The configuration type in te platform_app, domain, mlstrustedsubject; Can, because you add the permissions by MLS mechanism is rejected,