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
And I have defined following in file_contexts
/data/eeprom_data(/.*)? u:object_r:eeprom_data_file:s03
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.
Regards,
Sameer Joshi
On Fri, May 13, 2016 at 6:37 PM, Stephen Smalley <[email protected]> wrote:
> 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.<board>.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
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
