On 06/24/2014 01:27 PM, Dinesh Garg wrote:
> When I removed that rule, I got following error:
> 01-07 17:28:38.269 I/auditd  ( 1703): type=1400 audit(0.0:25): avc:
>  denied  { read write } for  comm="test" name="mmcblk0p23" dev="tmpfs"
> ino=9152 scontext=u:r:test:s0 tcontext=u:object_r:block_device:s0
> tclass=blk_file
> 
> When I removed block_device label as well I got following error:
> 01-07 17:53:03.289 I/auditd  ( 1925): type=1400 audit(0.0:24): avc:
>  denied  { read write } for  comm="test" name="mmcblk0p23" dev="tmpfs"
> ino=12335 scontext=u:r:test:s0 tcontext=u:object_r:device:s0 tclass=blk_file
> 
> Is there a way to provide precedence for the rules? I see following from
> file_contexts:
> /dev/block(/.*)?       u:object_r:block_device:s0
> /dev/block/loop[0-9]*   u:object_r:loop_device:s0
> /dev/block/ram[0-9]*    u:object_r:ram_device:s0
> 
> Is it that latest rule takes precedence ? I tried switching rules for
> ssd device:
> /dev/block/mmcblk.*    u:object_r:storage_partition_device:s0
> /dev/block/bootdevice/by-name/ssd  u:object_r:ssd_device:s0
> 
> But this also did not work and I got similar error as mentioned previously:
> 01-07 17:32:56.869 I/auditd  ( 1022): type=1400 audit(0.0:19): avc:
>  denied  { read write } for  comm="test" name="mmcblk0p23" dev="tmpfs"
> ino=12297 scontext=u:r:test:s0
> tcontext=u:object_r:storage_partition_device:s0 tclass=blk_file

lookup_best_match() first checks for an exact match on the real
pathname, then for an exact match against any of the link names, then
for the longest prefix match among all the names.  So in this scenario,
if /dev/block/bootdevice/by-name/ssd was in fact a link name created by
ueventd and passed to lookup_best_match(), then we should get that entry
regardless of order in the file.

The patch that I sent for system/core will show us what links names are
being passed to lookup_best_match().  I'd also like to know whether
/dev/block/bootdevice is in fact a real path or is itself a symlink.


_______________________________________________
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.

Reply via email to