I wonder if https://android.googlesource.com/platform/external/e2fsprogs/+/master/e2fsck/profile.c#270 is the cause. It's fstat'ing every file in the directory to see if it exists.
On Tue, Jan 19, 2016 at 8:44 AM William Roberts <[email protected]> wrote: > I was able to reproduce this on a device with sdcard support. > > [ 171.325196] type=1400 audit(1421405887.930:23): avc: denied { getattr } > for pid=2825 comm="e2fsck" path="/dev/block/zram0" dev="tmpfs" ino=11308 > scontext=u:r:fsck:s0 tcontext=u:object_r:swap_block_device:s0 > tclass=blk_file permissive=0 > > It works for us without this rule. This is likely related to vold as > Stephen pointed out calling the Format and Check routines (conjecture). > > dmesg: > [ 9.405740] fs_mgr: Running /system/bin/e2fsck on > /dev/block/by-name/data > [ 9.719493] e2fsck: e2fsck 1.42.9 (28-Dec-2013) > [ 9.719578] e2fsck: data: clean, 1177/262944 files, 48464/1050112 blocks > [ 9.786987] fs_mgr: Running /system/bin/e2fsck on > /dev/block/by-name/cache > [ 9.817792] e2fsck: e2fsck 1.42.9 (28-Dec-2013) > [ 9.817867] e2fsck: cache: clean, 16/6400 files, 1444/25600 blocks > > logcat: > 01-16 05:56:01.577 168 191 V vold : /system/bin/fsck_msdos > 01-16 05:56:25.902 674 1620 I BootReceiver: Checking for fsck errors > 01-16 05:58:07.832 168 191 D Vold : Running /system/bin/e2fsck on > /dev/block/dm-1 > 01-16 05:58:07.832 168 191 V vold : /system/bin/e2fsck > 01-16 05:58:07.940 168 191 I e2fsck : e2fsck 1.42.9 (28-Dec-2013) > 01-16 05:58:07.930 2825 2825 W e2fsck : type=1400 audit(0.0:23): avc: > denied { getattr } for path="/dev/block/zram0" dev="tmpfs" ino=11308 > scontext=u:r:fsck:s0 tcontext=u:object_r:swap_block_device:s0 > tclass=blk_file permissive=0 > 01-16 05:58:07.995 168 191 I e2fsck : /dev/block/dm-1: clean, > 11/485760 files, 34812/1941243 blocks > > > I see nothing failing, and we don't have this rule. As I said before, and > Jeff also re-iterated, if nothing is failing I would dontaudit this > and look into whats causing this. I don't really have time to debug this > is an entirety at this point in time. > > Bill > > On Tue, Jan 19, 2016 at 8:24 AM, Jeffrey Vander Stoep <[email protected]> > wrote: > >> Some options: >> >> 1. Ignore it. It's working as intended. >> 2. dontaudit it. Same as above but removes the denial >> 3. track down the source of the denial and fix. >> 4. File a bug against AOSP. >> >> On Tue, Jan 19, 2016 at 8:12 AM Inamdar Sharif <[email protected]> >> wrote: >> >>> Checked init.rc as well, that’s perfectly alright. >>> >>> This avc I am facing while formatting the sdcard as internal storage. >>> Any more ideas?? >>> >>> Thanks. >>> >>> -----Original Message----- >>> From: Seandroid-list [mailto:[email protected]] On >>> Behalf Of Inamdar Sharif >>> Sent: Tuesday, January 19, 2016 12:25 PM >>> To: Roberts, William C; William Roberts >>> Cc: [email protected] >>> Subject: RE: avc denial while enabling zram >>> >>> Yes we do have the same settings from SELinux POV. >>> We have the same code as the AOSP an no more additional changes on top >>> of it. >>> >>> I think I have to check how setting is done in init.rc . May be that’s >>> triggering that (Not sure , will try) I am using swapon_all for swap space >>> in init.rc. >>> >>> Thanks. >>> >>> -----Original Message----- >>> From: Roberts, William C [mailto:[email protected]] >>> Sent: Tuesday, January 19, 2016 12:50 AM >>> To: William Roberts; Inamdar Sharif >>> Cc: [email protected] >>> Subject: RE: avc denial while enabling zram >>> >>> The only thing we have is the label and for some reason (not sure why >>> offhand) a getattr for the swap_block file for vold. >>> >>> file_contexts:1:# ZRam device configured as swap space >>> file_contexts:2:/dev/block/zram0 u:object_r:swap_block_device:s0 >>> >>> vold.te:allow vold swap_block_device:blk_file getattr; >>> >>> We never had to allow any access from fsck. I see no dontaudits, so >>> perhaps were just ignoring the audit messages. >>> >>> Bill >>> >>> From: Seandroid-list [mailto:[email protected]] On >>> Behalf Of William Roberts >>> Sent: Monday, January 18, 2016 8:53 AM >>> To: Inamdar Sharif <[email protected]> >>> Cc: [email protected] >>> Subject: RE: avc denial while enabling zram >>> >>> Interesting, we have swap on zram on Intel devices and I don't recall >>> hearing of anything related to this. So we may just be doing a dontaudit or >>> ignoring it, not sure offhand. >>> On Jan 18, 2016 8:41 AM, "Inamdar Sharif" <[email protected]> wrote: >>> > >>> > >>Is that denial actually manifesting itself as some broken >>> functionality? >>> > >>> > As such it is not breaking anything. But this is seen while formatting >>> sdcard as internal storage. >>> > >>> > >>> > >>> > Also, why is fsck getting invoked on swap, especially one backed by >>> zram? >>> > >>> > Not sure about this but got something from the commit message which >>> says that we don’t have swap device on AOSP. >>> > >>> > >>> > >>> > <snip> >>> > >>> > e2fsck is invoked on any partitions marked with the check mount >>> > >>> > option in the fstab file, typically userdata and cache but never >>> > >>> > system. We allow it to read/write the userdata_block_device and >>> > >>> > cache_block_device types but also allow it to read/write the default >>> > >>> > block_device type until we can get the more specific types assigned >>> > >>> > in all of the device-specific policies. >>> > >>> > >>> > >>> > mkswap is invoked on any swap partition defined in the fstab file. >>> > >>> > We introduce a new swap_block_device type for this purpose, to be >>> > >>> > assigned to any such block devices in the device-specific policies, >>> > >>> > and only allow it to read/write such block devices. As there seem to >>> > be >>> > >>> > no devices in AOSP with swap partitions in their fstab files, this >>> > does >>> > >>> > not appear to risk any breakage for existing devices. >>> > >>> > </snip> >>> > >>> > >>> > >>> > Thanks. >>> > >>> > >>> > >>> > From: William Roberts [mailto:[email protected]] >>> > Sent: Monday, January 18, 2016 9:54 PM >>> > To: Inamdar Sharif >>> > Cc: [email protected] >>> > Subject: Re: avc denial while enabling zram >>> > >>> > >>> > >>> > Is that denial actually manifesting itself as some broken >>> functionality? >>> > >>> > Also, why is fsck getting invoked on swap, especially one backed by >>> zram? >>> > >>> > On Jan 18, 2016 8:20 AM, "Inamdar Sharif" <[email protected]> wrote: >>> > >>> > Hi Guys, >>> > >>> > >>> > >>> > I am facing the below avc denial while enabling zram. >>> > >>> > avc: denied { getattr } for pid=7545 comm="e2fsck" >>> > path="/dev/block/zram0" dev="tmpfs" ino=11973 scontext=u:r:fsck:s0 >>> > tcontext=u:object_r:swap_block_device:s0 tclass=blk_file permissive=0 >>> > >>> > >>> > >>> > I have labelled dev/block/zram0 as swap_block_device >>> > >>> > Also I have an entry in the fstab : >>> > >>> > /dev/block/zram0 none swap defaults >>> > zramsize=536870912 >>> > >>> > >>> > >>> > But due to neverallow rule in fsck.te the above permission cannot be >>> granted. >>> > >>> > # fsck should never be run on these block devices >>> > >>> > neverallow fsck { >>> > >>> > boot_block_device >>> > >>> > frp_block_device >>> > >>> > metadata_block_device >>> > >>> > recovery_block_device >>> > >>> > root_block_device >>> > >>> > swap_block_device >>> > >>> > system_block_device >>> > >>> > vold_device >>> > >>> > }:blk_file no_rw_file_perms; >>> > >>> > >>> > >>> > So I think we have to remove swap_block_device from the neverallow. >>> Any suggestions?? >>> > >>> > >>> > >>> > Thanks. >>> > >>> > ________________________________ >>> > >>> > This email message is for the sole use of the intended recipient(s) >>> and may contain confidential information. Any unauthorized review, use, >>> disclosure or distribution is prohibited. If you are not the intended >>> recipient, please contact the sender by reply email and destroy all copies >>> of the original message. >>> > >>> > ________________________________ >>> > >>> > >>> > _______________________________________________ >>> > Seandroid-list mailing list >>> > [email protected] >>> > To unsubscribe, send email to [email protected]. >>> > To get help, send an email containing "help" to >>> [email protected]. >>> >>> _______________________________________________ >>> Seandroid-list mailing list >>> [email protected] >>> To unsubscribe, send email to [email protected]. >>> To get help, send an email containing "help" to >>> [email protected]. >>> >>> _______________________________________________ >>> 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].
