Re: [HACKERS] sepgsql: label regression test failed
On 05/14/2014 07:33 AM, Sergey Muraviov wrote: I've got this compiler warning: relation.c: In function ‘sepgsql_relation_drop’: relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this function [-Wmaybe-uninitialized] sepgsql_avc_check_perms(object, ^ KaiGei, could you take a look at this warning, too? It looks like a genuine bug to me, but I'm not sure what we should do there instead. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sepgsql: label regression test failed
2014-05-16 16:26 GMT+09:00 Heikki Linnakangas hlinnakan...@vmware.com: On 05/14/2014 07:33 AM, Sergey Muraviov wrote: I've got this compiler warning: relation.c: In function ‘sepgsql_relation_drop’: relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this function [-Wmaybe-uninitialized] sepgsql_avc_check_perms(object, ^ KaiGei, could you take a look at this warning, too? It looks like a genuine bug to me, but I'm not sure what we should do there instead. This warning is harmless, because the code path that does not initialize tclass variable (a case when dropped relation is index) never goes to the code path that references tclass. It just checks schema's {remove_name} permission, then jumps to another code path for index, never backed. BTW, I could not produce this message in my environment with -Wall. (Fedora 20, gcc-4.8.2). Is it a newer compiler's wisdom? Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp sepgsql-fixup-maybe-uninitialized-warnning.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sepgsql: label regression test failed
Sorry, I've forgotten the report. The test fails on label test come from specification change in the mcs policy. Previously, it was applied to all the domains including unconfined_t, but now, it became to be applied on the domain with mcsconstrained attribute. This regression test run sepgsql_seton() on the system unconfined_t domain, and see the behavior when process intended to move wider or narrower ranged categories, so it was affected by system policy change, even though it is our intention of sepgsql. The attached patch adds mcsconstrained attribute on the domain for this regression test, if this attribute exists. So, it will work on both of F20 and older system. Regarding to the regression test on ddl and alter, this change looks to me hook invocation around recomputeNamespacePath() were gone, because the schema already allowed to search was already checked. Is the behavior around recomputeNamespacePath() recently updated? At least, it is not a matter since {search} permission towards regtest_schema_2 is checked in this test scenario. Thanks, 2014-05-14 13:33 GMT+09:00 Sergey Muraviov sergey.k.murav...@gmail.com: Hi. Some regression tests for sepgsql still not work on Fedora 20: == running regression test queries== test label... FAILED test dml ... ok test ddl ... FAILED test alter... FAILED test misc ... ok == 3 of 5 tests failed. == $ sestatus SELinux status: enabled SELinuxfs mount:/sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 29 $ uname -i -o -r 3.14.3-200.fc20.x86_64 x86_64 GNU/Linux $ /usr/local/pgsql/bin/postgres --version postgres (PostgreSQL) 9.4beta1 PS I've got this compiler warning: relation.c: In function ‘sepgsql_relation_drop’: relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this function [-Wmaybe-uninitialized] sepgsql_avc_check_perms(object, ^ 2013-12-25 0:34 GMT+04:00 Kohei KaiGai kai...@kaigai.gr.jp: Hello, It seems to me changes in the base security policy on Fedora affected to the regression test. Our test cases for sepgsql_setcon() utilizes the MCS rules, that prevents domain transition from narrow categories to wider ones, to control the success cases and failure cases. However, its coverage was changed. It was applied all the domains in the system, thus unconfined_t domain had been enforced by MCS rules. But now, it shall be applied only domains with mcs_constrained_type attribute. [kaigai@vmlinux tmp]$ diff -up old/policy/mcs new/policy/mcs : snip : mlsconstrain process { transition dyntransition } - (( h1 dom h2 ) or ( t1 == mcssetcats )); + (( h1 dom h2 ) or ( t1 != mcs_constrained_type )); Probably, we need to define a domain by ourselves for regression test to ensure the test stability, not using the system unconfined domain that has different meaning by release. I'll make a patch. Please wait for a while. Thanks for your test reports. 2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com: # semodule -l | grep sepgslq sepgsql-regtest 1.07 Full list of modules is in attachment. 2013/12/18 Kohei KaiGai kai...@kaigai.gr.jp Could you show me semodule -l on your environment? I believe security policy has not been changed between F19 and F20... Thanks, 2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com: Hi I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20 and met with a label regression test failure. PS I've got some warning during build process. -- Best regards, Sergey Muraviov -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- KaiGai Kohei kai...@kaigai.gr.jp -- Best regards, Sergey Muraviov -- KaiGai Kohei kai...@kaigai.gr.jp -- Best regards, Sergey Muraviov -- KaiGai Kohei kai...@kaigai.gr.jp sepgsql-fixup-regtest-policy.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sepgsql: label regression test failed
Hi. Some regression tests for sepgsql still not work on Fedora 20: == running regression test queries== test label... FAILED test dml ... ok test ddl ... FAILED test alter... FAILED test misc ... ok == 3 of 5 tests failed. == $ sestatus SELinux status: enabled SELinuxfs mount:/sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 29 $ uname -i -o -r 3.14.3-200.fc20.x86_64 x86_64 GNU/Linux $ /usr/local/pgsql/bin/postgres --version postgres (PostgreSQL) 9.4beta1 PS I've got this compiler warning: relation.c: In function ‘sepgsql_relation_drop’: relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this function [-Wmaybe-uninitialized] sepgsql_avc_check_perms(object, ^ 2013-12-25 0:34 GMT+04:00 Kohei KaiGai kai...@kaigai.gr.jp: Hello, It seems to me changes in the base security policy on Fedora affected to the regression test. Our test cases for sepgsql_setcon() utilizes the MCS rules, that prevents domain transition from narrow categories to wider ones, to control the success cases and failure cases. However, its coverage was changed. It was applied all the domains in the system, thus unconfined_t domain had been enforced by MCS rules. But now, it shall be applied only domains with mcs_constrained_type attribute. [kaigai@vmlinux tmp]$ diff -up old/policy/mcs new/policy/mcs : snip : mlsconstrain process { transition dyntransition } - (( h1 dom h2 ) or ( t1 == mcssetcats )); + (( h1 dom h2 ) or ( t1 != mcs_constrained_type )); Probably, we need to define a domain by ourselves for regression test to ensure the test stability, not using the system unconfined domain that has different meaning by release. I'll make a patch. Please wait for a while. Thanks for your test reports. 2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com: # semodule -l | grep sepgslq sepgsql-regtest 1.07 Full list of modules is in attachment. 2013/12/18 Kohei KaiGai kai...@kaigai.gr.jp Could you show me semodule -l on your environment? I believe security policy has not been changed between F19 and F20... Thanks, 2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com: Hi I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20 and met with a label regression test failure. PS I've got some warning during build process. -- Best regards, Sergey Muraviov -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- KaiGai Kohei kai...@kaigai.gr.jp -- Best regards, Sergey Muraviov -- KaiGai Kohei kai...@kaigai.gr.jp -- Best regards, Sergey Muraviov regression.diffs Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sepgsql: label regression test failed
Hello, It seems to me changes in the base security policy on Fedora affected to the regression test. Our test cases for sepgsql_setcon() utilizes the MCS rules, that prevents domain transition from narrow categories to wider ones, to control the success cases and failure cases. However, its coverage was changed. It was applied all the domains in the system, thus unconfined_t domain had been enforced by MCS rules. But now, it shall be applied only domains with mcs_constrained_type attribute. [kaigai@vmlinux tmp]$ diff -up old/policy/mcs new/policy/mcs : snip : mlsconstrain process { transition dyntransition } - (( h1 dom h2 ) or ( t1 == mcssetcats )); + (( h1 dom h2 ) or ( t1 != mcs_constrained_type )); Probably, we need to define a domain by ourselves for regression test to ensure the test stability, not using the system unconfined domain that has different meaning by release. I'll make a patch. Please wait for a while. Thanks for your test reports. 2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com: # semodule -l | grep sepgslq sepgsql-regtest 1.07 Full list of modules is in attachment. 2013/12/18 Kohei KaiGai kai...@kaigai.gr.jp Could you show me semodule -l on your environment? I believe security policy has not been changed between F19 and F20... Thanks, 2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com: Hi I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20 and met with a label regression test failure. PS I've got some warning during build process. -- Best regards, Sergey Muraviov -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- KaiGai Kohei kai...@kaigai.gr.jp -- Best regards, Sergey Muraviov -- KaiGai Kohei kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sepgsql: label regression test failed
Could you show me semodule -l on your environment? I believe security policy has not been changed between F19 and F20... Thanks, 2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com: Hi I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20 and met with a label regression test failure. PS I've got some warning during build process. -- Best regards, Sergey Muraviov -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- KaiGai Kohei kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sepgsql: label regression test failed
# semodule -l | grep sepgslq sepgsql-regtest 1.07 Full list of modules is in attachment. 2013/12/18 Kohei KaiGai kai...@kaigai.gr.jp Could you show me semodule -l on your environment? I believe security policy has not been changed between F19 and F20... Thanks, 2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com: Hi I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20 and met with a label regression test failure. PS I've got some warning during build process. -- Best regards, Sergey Muraviov -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- KaiGai Kohei kai...@kaigai.gr.jp -- Best regards, Sergey Muraviov modules Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers