On Thu, Jun 2, 2016 at 6:35 AM, Sameer Joshi <[email protected]> wrote:
> Thanks Stephen. It was my mistake that I did not do mkdir for > eeprom_data_file correctly. > After fixing this, it worked fine. > I was using wrong user. cpnoui executes with user root and group system. > After modifying user and group for eeprom_data_file during mkdir, issue was > solved. > Running steady services (ie not-oneshot) with root will fail CTS. You shouldn't really run services as user root, with very few exceptions. In one case is things writing to kmsg like init. You should pick a non root uid and use android_filesystem_config.h to assign any needed capabilities. Examples exist for some nexus devices, shamu as one. If your on master, that has switched over to using config.fs ini files. Additionally, perhaps using a non-core user is best, and you can assign a uid in the oem reserved range (see android_filesystem_config.h) under system/core. (just do find). init services allow for number strings as user and group. > > Thanks again. > > On Thu, Jun 2, 2016 at 6:09 PM, Stephen Smalley <[email protected]> wrote: > >> On 06/02/2016 06:59 AM, Sameer Joshi wrote: >> > Hi Stephen, >> > >> > I tried what you said: >> > >> > I have done following on trigger of post-fs-data in init.<board>.rc >> file: >> > >> > mkdir /data/eeprom_data 777 system >> >> Why mode 777? What else besides cpnoui needs access, and especially >> what else needs write access? Why are you assigning it the system UID? >> Is that what cpnoui runs in? What group ownership should it have? >> >> > And I have defined following in file_contexts >> > >> > /data/eeprom_data(/.*)? u:object_r:eeprom_data_file:s03 >> >> Is the trailing "3" above a typo? >> That would make the context invalid, but you should then be getting an >> error at build time. >> >> > >> > Did following in cpnoui.te: >> > >> > allpw cpnoui eeprom_data_file:dir rw_dir_perms; >> > allow cpnoui eeprom_data_file:file create_file_perms; >> > >> > Also my program cpnoui is writing to a file under /data/eeprom_data/ >> > >> > Still its giving the same error: >> > >> > type=1400 audit(1463139871.920:5): avc: denied { create } for pid=167 >> > comm="sh" name="eeprom_data_from_sysprops.tmp" scontext=u:r:cpnoui:s0 >> > tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0 >> > >> > Do I need to create the directory after specific trigger to make it >> > readable by init as eeprom_data_file instead of system_data_file. >> >> No, if you have a matching entry with a valid context in /file_contexts >> on the device, and if init is creating the directory (i.e. if the >> directory does not already exist), then the directory should be created >> with the context specified by the matching entry. Further, even if the >> directory already existed, if /file_contexts has changed since the last >> boot (e.g. OTA), then the restorecon_recursive /data should relabel it >> accordingly. >> >> Things to check: >> 1. What is the current label of /data/eeprom_data? >> ls -Z /data/eeprom_data >> >> 2. Does the file_contexts on the device include the entry you added? >> adb shell grep /data/eeprom_data /file_contexts >> >> 3. What does restorecon think the label of /data/eeprom_data should be? >> adb shell restorecon -nv /data/eeprom_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]. > -- Respectfully, William C Roberts
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
