On Tue, Jan 19, 2016 at 12:26 PM, William Roberts <[email protected]> wrote:
> > On Jan 19, 2016 12:20 PM, "Jeffrey Vander Stoep" <[email protected]> wrote: > > > > Try adding notrim in your fstab. Trimming swap makes no sense. > > Does defaults include discard? I haven't looked. > Ok I see that notrim is a fs manager flag, not a mount option. > > > > > On Tue, Jan 19, 2016 at 9:31 AM William Roberts < > [email protected]> wrote: > >> > >> 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: > >>>>>> Ignore it. It's working as intended. > >>>>>> dontaudit it. Same as above but removes the denial > >>>>>> track down the source of the denial and fix. > >>>>>> 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 > >> > > -- 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].
