Does your zram have the notrim option set in the fstab? e.g. https://android.googlesource.com/device/htc/flounder/+/master/fstab.flounder#16
On Tue, Jan 19, 2016 at 9:18 AM Jeffrey Vander Stoep <[email protected]> wrote: > 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].
