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 . _______________________________________________ tomoyo-users-en mailing list tomoyo-users-en@lists.osdn.me http://lists.osdn.me/mailman/listinfo/tomoyo-users-en
