On 7 June 2016 at 13:32, Tetsuo Handa <pengu****@i-lov*****> wrote: > Roman Yeryomin wrote: >> Just tried CaitSith on 4.1 kernel and getting this: >> >> [ 10.403615] ------------[ cut here ]------------ >> [ 10.408411] WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:2668 __alloc_pages_nodemask+0x164/0x624() > (...snipped...) >> [ 10.586902] ERROR: Out of memory at cs_realpath. >> [ 10.591679] CaitSith: Rejecting access request due to out of memory. > > Thank you for reporting this problem. I think this is a bug which occurs > when using CaitSith on Linux 3.17 and later kernels with overlayfs. I fixed > this problem ( https://osdn.jp/projects/caitsith/scm/svn/commits/186 ). > > I tested with > > ---------- > # mkdir -p /mnt/a /mnt/b > # mount -t xfs /dev/sdb1 /mnt/a/ > # mount -t tmpfs none /mnt/b/ > # mkdir /mnt/b/rw > # mkdir /mnt/b/work > # mount -t overlay -o lowerdir=/mnt/a/,upperdir=/mnt/b/rw/,workdir=/mnt/b/work/ overlayfs /mnt/ > ---------- > > and a rule > > ---------- > quota audit[1] allowed=0 denied=1024 unmatched=1024 > 10 acl read path.type=directory > audit 1 > ---------- > > and got similar one. > > ---------- > [ 157.480446] ------------[ cut here ]------------ > [ 157.486088] WARNING: CPU: 3 PID: 1175 at mm/slab_common.c:766 kmalloc_slab+0x85/0xa0() > [ 157.495795] Modules linked in: caitsith(O) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_filter ppdev vmw_vmci pcspkr coretemp i2c_piix4 parport_pc parport shpchp ip_tables xfs libcrc32c sd_mod sr_mod cdrom ata_generic pata_acpi mptspi scsi_transport_spi mptscsih serio_raw e1000 vmwgfx drm_kms_helper ttm drm ata_piix mptbase libata i2c_core > [ 157.537349] CPU: 3 PID: 1175 Comm: bash Tainted: G O 4.1.16 #10 > [ 157.541707] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 > [ 157.548571] 0000000000000497 000000006717d855 ffffffff81794cce ffffffff8152828c > [ 157.553372] 0000000000000000 ffffffff810578b7 ffff88003b000000 0000000000000050 > [ 157.558121] ffff8800394979b8 ffff88003d57b000 ffff880039497670 ffffffff8111bec5 > [ 157.562855] Call Trace: > [ 157.564423] [<ffffffff8152828c>] ? dump_stack+0x40/0x50 > [ 157.568007] [<ffffffff810578b7>] ? warn_slowpath_common+0x77/0xb0 > [ 157.571794] [<ffffffff8111bec5>] ? kmalloc_slab+0x85/0xa0 > [ 157.575154] [<ffffffff8114a1d1>] ? __kmalloc+0x11/0x150 > [ 157.578853] [<ffffffffa0278891>] ? cs_realpath+0x61/0x4c0 [caitsith] > [ 157.583213] [<ffffffff8117801a>] ? prepend_path+0xda/0x2d0 > [ 157.587198] [<ffffffffa026fae1>] ? cs_populate_patharg+0x81/0xb0 [caitsith] > [ 157.591994] [<ffffffffa02749f8>] ? cs_init_log+0x1088/0x12d0 [caitsith] > [ 157.596581] [<ffffffffa0278025>] ? cs_audit_log+0x85/0x4a0 [caitsith] > [ 157.601269] [<ffffffffa0270c0c>] ? cs_check_acl+0x11c/0x220 [caitsith] > [ 157.605768] [<ffffffffa027131c>] ? cs_open_permission+0xfc/0x140 [caitsith] > [ 157.610537] [<ffffffffa0279d88>] ? cs_file_open+0x18/0x50 [caitsith] > [ 157.614941] [<ffffffff811fbbe4>] ? security_file_open+0x14/0x70 > [ 157.619066] [<ffffffff8115fd92>] ? do_dentry_open+0xb2/0x320 > [ 157.623053] [<ffffffff811ea180>] ? ovl_dir_fsync+0x130/0x130 > [ 157.627027] [<ffffffff8116108f>] ? dentry_open+0x3f/0xb0 > [ 157.630804] [<ffffffff8114a580>] ? kmem_cache_alloc+0x120/0x130 > [ 157.634933] [<ffffffff811ea1d2>] ? ovl_dir_open+0x52/0xc0 > [ 157.638756] [<ffffffff8115feea>] ? do_dentry_open+0x20a/0x320 > [ 157.642781] [<ffffffff8116e29e>] ? do_last+0x41e/0xfc0 > [ 157.646596] [<ffffffff8114a580>] ? kmem_cache_alloc+0x120/0x130 > [ 157.650725] [<ffffffff81170a0e>] ? path_openat+0x8e/0x630 > [ 157.654532] [<ffffffff8117218e>] ? do_filp_open+0x3e/0xa0 > [ 157.658337] [<ffffffff8117e24c>] ? __alloc_fd+0x7c/0x120 > [ 157.662290] [<ffffffff811613f8>] ? do_sys_open+0x148/0x230 > [ 157.666140] [<ffffffff8152e157>] ? system_call_fastpath+0x12/0x6a > [ 157.670365] ---[ end trace ff1fe2bff03c9b4d ]--- > [ 157.673671] ERROR: Out of memory at cs_realpath. > ---------- > >> Any idea why? >> Didn't have this problem with Tomoyo > > Since overlayfs combines underlying mounts, not only pathname seen from > the overlayfs but also pathnames seen from underlying mounts are subjected > for permission checks. But d_absolute_path() for underlying mounts was > returning -EINVAL error. While TOMOYO has a fallback to calculate local > pathname, I forgot to apply it to CaitSith for Linux 3.17 and later kernels. > > > > I don't know how partitions are mounted in your environment, but according > to https://wiki.openwrt.org/doc/techref/flash.layout , it seems to me that > overlayfs is mounted on / after SquashFS is mounted on /rom and JFFS2 is > mounted on /overlay . If so, applications cannot directly access pathnames > under /rom and /overlay , which means that it makes little sense to check > permissions for pathnames seen from SquashFS and JFFS2. In that case, you > might want to check permissions for only pathname seen from overlayfs using > filesystem magic number for overlayfs (i.e. 0x794C7630) like > > 10 acl read path.fsmagic=0x794C7630 > > instead of > > 10 acl read > Thank you for fixing this! Although I will probably stick with Tomoyo for some time I will probably migrate to CaitSith in the future as it seems more powerful and flexible. Regards, Roman
TOMOYO
Fork