Yes, /dev/block/bootdevice is a link as well.

I will apply new patch you sent in mail and update the list.

Thanks,
Dinesh


On Tue, Jun 24, 2014 at 10:35 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote:

> 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