Re: Regarding issue in defining file in file_contexts
On Thu, Jun 2, 2016 at 6:35 AM, Sameer Joshiwrote: > 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 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..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 > Seandroid-list@tycho.nsa.gov > To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. > To get help, send an email containing "help" to > seandroid-list-requ...@tycho.nsa.gov. > -- Respectfully, William C Roberts ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
Re: Regarding issue in defining file in file_contexts
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..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 Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
Re: Regarding issue in defining file in file_contexts
On 05/13/2016 07:52 AM, Sameer Joshi wrote: > Hi, > > I have defined following file context in file_contexts: > > /data/eeprom_data_from_sysprops\.tmp u:object_r:eeprom_data_file:s0 > > and following in file.te: > > type eeprom_data_file, file_type, data_file_type; > > Also I have added following in cpnoui.te ( a new domain defined for an > executable) : > > > allow cpnoui eeprom_data_file:file create; > > Still I get following 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 > > This indicates that eeprom_data_from_sysprops.tmp file is still not > being as from the domain eeprom_data_file, > > Please let me know what could be the problem. file_contexts is a userspace configuration used at build time to label the initial filesystem images and consulted by specific programs (e.g. init, ueventd, etc) at runtime to determine labels for directories and files they create. It is not used by the kernel and won't affect runtime file creation. For the latter, you would need a type_transition rule in your policy, ala type_transition cpnoui system_data_file:file eeprom_data_file; However, this is NOT the recommended way to solve this problem. It would be better to define a separate subdirectory of /data for this file (e.g. /data/eeprom_data), create this directory from your init..rc file, assign the directory and all files within it a label in file_contexts (e.g. /data/eeprom_data(/.*)? u:object_r:eeprom_data_file:s0), and then create your file in this directory (i.e. /data/eeprom_data/eeprom_data_from_sysprops.tmp, or whatever name you choose to use). This approach has the following advantages: 1) Your process (cpnoui) will not need { write add_name } permissions to system_data_file:dir (and hence won't be allowed to write to other /data directories it has no business modifying). 2) init already uses file_contexts to determine the label of directories it creates, so it will create the directory in the right label automatically. 3) When your process creates files in that directory, they will automatically inherit the type of the parent directory and you won't need to explicitly label them. Regardless, when allowing permissions, please using the macros in global_macros. Instead of merely allowing create (and then running into denials when your process tries to perform any other operation), use create_file_perms, ala: allpw cpnoui eeprom_data_file:dir rw_dir_perms; allow cpnoui eeprom_data_file:file create_file_perms; ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
Regarding issue in defining file in file_contexts
Hi, I have defined following file context in file_contexts: /data/eeprom_data_from_sysprops\.tmp u:object_r:eeprom_data_file:s0 and following in file.te: type eeprom_data_file, file_type, data_file_type; Also I have added following in cpnoui.te ( a new domain defined for an executable) : allow cpnoui eeprom_data_file:file create; Still I get following 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 This indicates that eeprom_data_from_sysprops.tmp file is still not being as from the domain eeprom_data_file, Please let me know what could be the problem. Regards, Sameer Joshi ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.