source: boot/common/changingowner.xml@ 0869232

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../../general.ent">
  %general-entities;
]>

<sect1 id="ch-boot-changingowner">
  <?dbhtml filename="changingowner.html"?>

  <title>Changing Ownership</title>

  <note os="a">
    <para>From now on, all commands in the rest of the book will be run as the <systemitem class="username">root</systemitem> user.</para>
  </note>

  <para os="b">Currently, the <filename class="directory">/tools</filename>
  directory, <filename class="directory">/cross-tools</filename> directory, and
  <filename class="directory">$LFS</filename> directory are owned
  by the user <systemitem class="username">lfs</systemitem>,
  a user that exists only on the host system. For security reasons, the $LFS root directory and all of it subdirectories should be owned by <systemitem class="username">root</systemitem>. Change the ownership for $LFS and its subdirectories by running these commands:</para>

<screen><userinput>chown 0:0 ${LFS}
chown -R 0:0 $LFS/{bin,boot,dev,etc,home,lib,media,mnt,opt,proc,root,sbin,srv,sys,tmp,usr,var}</userinput></screen>

  <para os="c">The same issue also exists with <filename class="directory">/tools</filename> and <filename class="directory">/cross-tools</filename>. Although these directories can be deleted once the
  LFS system has been finished, they can be retained to build additional
  LFS systems. If the <filename class="directory">/tools</filename> and <filename class="directory">/cross-tools</filename>
  directories are kept as is, the files are owned by a user ID without a
  corresponding account. This is dangerous because a user account created
  later could get this same user ID and would own the <filename
  class="directory">/tools</filename> and <filename class="directory">/cross-tools</filename> directories and all the files therein,
  thus exposing these files to possible malicious manipulation.</para>

  <para os="d">To avoid this issue, add the <systemitem
  class="username">lfs</systemitem> user to the new LFS system later when
  creating the <filename>/etc/passwd</filename> file, taking care to assign
  it the same user and group IDs as on the host system. Alternatively,
  assign the contents of the <filename class="directory">/tools</filename>
  and <filename class="directory">/cross-tools</filename> directories to user <systemitem class="username">root</systemitem> by running
  the following command:</para>

<screen><userinput>chown -R 0:0 /tools
chown -R 0:0 /cross-tools</userinput></screen>

<para os="e">This book assumes you ran these <command>chown</command> commands.</para>

<!--  <para os="c">The command uses <parameter>0:0</parameter> instead of
  <parameter>root:root</parameter>, because <command>chown</command>
  is unable to resolve the name <quote>root</quote> until the password
  file has been created. This book assumes you ran this
  <command>chown</command> command.</para> -->

</sect1>