Date: Fri, 17 May 2013 17:26:21 +0000 (UTC) From: Tom Rhodes <trhodes@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org Subject: svn commit: r41640 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/mac Message-ID: <201305171726.r4HHQLwc042957@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: trhodes Date: Fri May 17 17:26:20 2013 New Revision: 41640 URL: http://svnweb.freebsd.org/changeset/doc/41640 Log: Whitespace love after previous commit. Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/mac/chapter.xml Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/mac/chapter.xml ============================================================================== --- projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/mac/chapter.xml Fri May 17 16:02:26 2013 (r41639) +++ projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/mac/chapter.xml Fri May 17 17:26:20 2013 (r41640) @@ -1809,134 +1809,135 @@ setpmac biba/10\(10-10\) /usr/local/etc/ <itemizedlist> <listitem> - <para>The <option>multilabel</option> flag does not stay - enabled on my root (<filename>/</filename>) partition!</para> + <para>The <option>multilabel</option> flag does not stay + enabled on my root (<filename>/</filename>) partition!</para> - <para>The following steps may resolve this transient - error:</para> + <para>The following steps may resolve this transient + error:</para> - <procedure> - <step> - <para>Edit <filename>/etc/fstab</filename> and set the root - partition to <option>ro</option> for read-only.</para> - </step> - - <step> - <para>Reboot into single user mode.</para> - </step> + <procedure> + <step> + <para>Edit <filename>/etc/fstab</filename> and set the root + partition to <option>ro</option> for read-only.</para> + </step> + + <step> + <para>Reboot into single user mode.</para> + </step> - <step> - <para>Run <command>tunefs</command> <option>-l + <step> + <para>Run <command>tunefs</command> <option>-l enable</option> - on <filename>/</filename>.</para> - </step> + on <filename>/</filename>.</para> + </step> - <step> - <para>Reboot the system.</para> - </step> - - <step> - <para>Run <command>mount</command> <option>-urw</option> - <filename>/</filename> and change the <option>ro</option> - back to <option>rw</option> in - <filename>/etc/fstab</filename> and reboot the system - again.</para> - </step> - - <step> - <para>Double-check the output from - <command>mount</command> to ensure that - <option>multilabel</option> has been properly set on the - root file system.</para> - </step> - </procedure> - </listitem> - - <listitem> - <para>After establishing a secure environment with - <acronym>MAC</acronym>, I am no longer able to start - Xorg!</para> - - <para>This could be caused by the <acronym>MAC</acronym> - <literal>partition</literal> policy or by a mislabeling in - one of the <acronym>MAC</acronym> labeling policies. To - debug, try the following:</para> - - <procedure> - <step> - <para>Check the error message; if the user is in the - <literal>insecure</literal> class, the - <literal>partition</literal> policy may be the culprit. - Try setting the user's class back to the - <literal>default</literal> class and rebuild the database - with <command>cap_mkdb</command>. If this does not - alleviate the problem, go to step two.</para> - </step> - - <step> - <para>Double-check the label policies. Ensure that the - policies are set correctly for the user, the Xorg - application, and the <filename - class="directory">/dev</filename> entries.</para> - </step> - - <step> - <para>If neither of these resolve the problem, send the - error message and a description of the environment to - the &a.questions; mailing list.</para> - </step> - </procedure> - </listitem> - - <listitem> - <para>The error: <errorname>_secure_path: unable to stat .login_conf</errorname> shows up.</para> - - <para>When a user attempts to switch from the - <username>root</username> user to another user in the system, - the error message <errorname>_secure_path: unable to stat + <step> + <para>Reboot the system.</para> + </step> + + <step> + <para>Run <command>mount</command> <option>-urw</option> + <filename>/</filename> and change the <option>ro</option> + back to <option>rw</option> in + <filename>/etc/fstab</filename> and reboot the system + again.</para> + </step> + + <step> + <para>Double-check the output from + <command>mount</command> to ensure that + <option>multilabel</option> has been properly set on the + root file system.</para> + </step> + </procedure> + </listitem> + + <listitem> + <para>After establishing a secure environment with + <acronym>MAC</acronym>, I am no longer able to start + Xorg!</para> + + <para>This could be caused by the <acronym>MAC</acronym> + <literal>partition</literal> policy or by a mislabeling in + one of the <acronym>MAC</acronym> labeling policies. To + debug, try the following:</para> + + <procedure> + <step> + <para>Check the error message; if the user is in the + <literal>insecure</literal> class, the + <literal>partition</literal> policy may be the culprit. + Try setting the user's class back to the + <literal>default</literal> class and rebuild the database + with <command>cap_mkdb</command>. If this does not + alleviate the problem, go to step two.</para> + </step> + + <step> + <para>Double-check the label policies. Ensure that the + policies are set correctly for the user, the Xorg + application, and the <filename + class="directory">/dev</filename> entries.</para> + </step> + + <step> + <para>If neither of these resolve the problem, send the + error message and a description of the environment to + the &a.questions; mailing list.</para> + </step> + </procedure> + </listitem> + + <listitem> + <para>The error: <errorname>_secure_path: unable to stat + .login_conf</errorname> shows up.</para> + + <para>When a user attempts to switch from the + <username>root</username> user to another user in the system, + the error message <errorname>_secure_path: unable to stat .login_conf</errorname> appears.</para> - <para>This message is usually shown when the user has a higher - label setting than that of the user they are attempting to - become. For instance, <username>joe</username> has a default - label of <option>biba/low</option>. The - <username>root</username> user, who has a label of - <option>biba/high</option>, cannot view - <username>joe</username>'s home directory. This will happen - whether or not <username>root</username> has used - <command>su</command> to become <username>joe</username> as - the Biba integrity model will not permit - <username>root</username> to view objects set at a lower - integrity level.</para> - </listitem> - - <listitem> - <para>The system no longer recognizes the - <username>root</username> user.</para> - - <para>In normal or even single user mode, the - <username>root</username> is not recognized, - <command>whoami</command> returns 0 (zero), and - <command>su</command> returns <errorname>who are + <para>This message is usually shown when the user has a higher + label setting than that of the user they are attempting to + become. For instance, <username>joe</username> has a default + label of <option>biba/low</option>. The + <username>root</username> user, who has a label of + <option>biba/high</option>, cannot view + <username>joe</username>'s home directory. This will happen + whether or not <username>root</username> has used + <command>su</command> to become <username>joe</username> as + the Biba integrity model will not permit + <username>root</username> to view objects set at a lower + integrity level.</para> + </listitem> + + <listitem> + <para>The system no longer recognizes the + <username>root</username> user.</para> + + <para>In normal or even single user mode, the + <username>root</username> is not recognized, + <command>whoami</command> returns 0 (zero), and + <command>su</command> returns <errorname>who are you?</errorname>.</para> - <para>This can happen if a labeling policy has been disabled, - either by a &man.sysctl.8; or the policy module was unloaded. - If the policy is disabled, the login capabilities database - needs to be reconfigured with <option>label</option> removed. - Double check <filename>login.conf</filename> to ensure that - all <option>label</option> options have been removed and - rebuild the database with <command>cap_mkdb</command>.</para> - - <para>This may also happen if a policy restricts access to - <filename>master.passwd</filename>. This is usually caused by - an administrator altering the file under a label which - conflicts with the general policy being used by the system. - In these cases, the user information would be read by the - system and access would be blocked as the file has inherited - the new label. Disable the policy using &man.sysctl.8; and - everything should return to normal.</para> - </listitem> - </itemizedlist> + <para>This can happen if a labeling policy has been disabled, + either by a &man.sysctl.8; or the policy module was unloaded. + If the policy is disabled, the login capabilities database + needs to be reconfigured with <option>label</option> removed. + Double check <filename>login.conf</filename> to ensure that + all <option>label</option> options have been removed and + rebuild the database with <command>cap_mkdb</command>.</para> + + <para>This may also happen if a policy restricts access to + <filename>master.passwd</filename>. This is usually caused by + an administrator altering the file under a label which + conflicts with the general policy being used by the system. + In these cases, the user information would be read by the + system and access would be blocked as the file has inherited + the new label. Disable the policy using &man.sysctl.8; and + everything should return to normal.</para> + </listitem> + </itemizedlist> </sect1> </chapter>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305171726.r4HHQLwc042957>