Something is causing checkpolicy to segfault. I ended up building it from the .src.rpm so it was compiled with -g and not stripped.
checkpolicy-1.27.1-1, libselinux-1.26-6, updated to -devel tree as of this morning.
gdb then says:
(gdb) run -M -o policy.20 policy.conf Starting program: /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy -M -o policy.20 policy.conf Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy: loading policy configuration from policy.conf
Program received signal SIGSEGV, Segmentation fault. parse_categories (id=0x8bbff28 "s0", levdatum=0x80a75b8, cats=0x80a00bc) at policy_parse.y:3569 3569 range_start = range_end = cdatum->value - 1; (gdb) where #0 parse_categories (id=0x8bbff28 "s0", levdatum=0x80a75b8, cats=0x80a00bc) at policy_parse.y:3569 #1 0x0804f340 in parse_security_context (c=0x80a00ac) at policy_parse.y:3850 #2 0x080534f2 in yyparse () at policy_parse.y:3925 #3 0x0804a743 in main (argc=5, argv=0xbfeecd74) at checkpolicy.c:549
This ring any bells? Have I dorked up a file ('users' most likely) during the conversion to MCS in a way that didn't flag a syntax error but causes a crash? Hints, etc accepted..
Valdis.Kletnieks@vt.edu wrote:
Something is causing checkpolicy to segfault. I ended up building it from the .src.rpm so it was compiled with -g and not stripped.
checkpolicy-1.27.1-1, libselinux-1.26-6, updated to -devel tree as of this morning.
gdb then says:
(gdb) run -M -o policy.20 policy.conf Starting program: /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy -M -o policy.20 policy.conf Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy: loading policy configuration from policy.conf
Program received signal SIGSEGV, Segmentation fault. parse_categories (id=0x8bbff28 "s0", levdatum=0x80a75b8, cats=0x80a00bc) at policy_parse.y:3569 3569 range_start = range_end = cdatum->value - 1; (gdb) where #0 parse_categories (id=0x8bbff28 "s0", levdatum=0x80a75b8, cats=0x80a00bc) at policy_parse.y:3569 #1 0x0804f340 in parse_security_context (c=0x80a00ac) at policy_parse.y:3850 #2 0x080534f2 in yyparse () at policy_parse.y:3925 #3 0x0804a743 in main (argc=5, argv=0xbfeecd74) at checkpolicy.c:549
This ring any bells? Have I dorked up a file ('users' most likely) during the conversion to MCS in a way that didn't flag a syntax error but causes a crash? Hints, etc accepted..
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
libsetrans is borked.
On Tue, 2005-09-20 at 16:31 -0400, Valdis.Kletnieks@vt.edu wrote:
Something is causing checkpolicy to segfault. I ended up building it from the .src.rpm so it was compiled with -g and not stripped.
checkpolicy-1.27.1-1, libselinux-1.26-6, updated to -devel tree as of this morning.
gdb then says:
(gdb) run -M -o policy.20 policy.conf Starting program: /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy -M -o policy.20 policy.conf Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy: loading policy configuration from policy.conf
Program received signal SIGSEGV, Segmentation fault. parse_categories (id=0x8bbff28 "s0", levdatum=0x80a75b8, cats=0x80a00bc) at policy_parse.y:3569 3569 range_start = range_end = cdatum->value - 1; (gdb) where #0 parse_categories (id=0x8bbff28 "s0", levdatum=0x80a75b8, cats=0x80a00bc) at policy_parse.y:3569 #1 0x0804f340 in parse_security_context (c=0x80a00ac) at policy_parse.y:3850 #2 0x080534f2 in yyparse () at policy_parse.y:3925 #3 0x0804a743 in main (argc=5, argv=0xbfeecd74) at checkpolicy.c:549
This ring any bells? Have I dorked up a file ('users' most likely) during the conversion to MCS in a way that didn't flag a syntax error but causes a crash? Hints, etc accepted..
From the info above, you have an id "s0" that is a sensitivity rather
than a category, so the hashtab_search fails, but that code path fails to check for such failure and thus crashes rather than reporting it. Try the patch below.
Index: checkpolicy/policy_parse.y =================================================================== RCS file: /nfshome/pal/CVS/selinux-usr/checkpolicy/policy_parse.y,v retrieving revision 1.43 diff -u -p -r1.43 policy_parse.y --- checkpolicy/policy_parse.y 16 Sep 2005 17:24:11 -0000 1.43 +++ checkpolicy/policy_parse.y 20 Sep 2005 20:38:34 -0000 @@ -3566,6 +3566,11 @@ parse_categories(char *id, level_datum_t } else { cdatum = (cat_datum_t *)hashtab_search(policydbp->p_cats.table, (hashtab_key_t)id); + if (!cdatum) { + sprintf(errormsg, "unknown category %s", id); + yyerror(errormsg); + return -1; + } range_start = range_end = cdatum->value - 1; }
On Tue, 20 Sep 2005 16:41:26 EDT, Stephen Smalley said:
From the info above, you have an id "s0" that is a sensitivity rather
than a category, so the hashtab_search fails, but that code path fails to check for such failure and thus crashes rather than reporting it. Try the patch below.
OK.. No crash, something resembling a useful diagnostic. Probably want to keep the patch....
(gdb) run -M -o policy.20 policy.conf Starting program: /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy -M -o policy.20 policy.conf Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy: loading policy configuration from policy.conf initial_sid_contexts:9:ERROR 'unknown category s0' at token 'sid' on line 428578: sid security system_u:object_r:security_t:s0:s0 sid kernel system_u:system_r:kernel_t:s0:s0 /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy: error(s) encountered while parsing configuration
"D'oh!" -- H. Simpson
After fixing initial_sid_contexts by hand, I got:
fs_use:8:ERROR 'unknown category s0' at token ';' on line 428624: fs_use_xattr ext2 system_u:object_r:fs_t:s0:s0; # Requires that a security xattr handler exist for the filesystem.
I think I trashed it by running 'make mcsconvert' (possibly twice) trying to deal with the fact that my 'users' file didn't have :s0 type stuff in it....
Ended up doing an 'rpm -e selinux-policy-strict-sources' and then re-installing it, all looks OK now.
selinux@lists.fedoraproject.org