1. The no logging on the stat failure is consistent to what I am seeing. So you might have the correct spot. 2. The fstab entry: /dev/block/zram0 none swap defaults zramsize=419430400
I wanted to run a test with fsck in permissive to see if it only requests getattr, or if it requests more. The pattern of requests might help deduce the area of code executing. On Tue, Jan 19, 2016 at 9:28 AM, Jeffrey Vander Stoep <[email protected]> wrote: > 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 >>> >>> -- 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].
