<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>
<sect1 id="ch-system-changingowner">
<title>Changing ownership</title>
<?dbhtml filename="changingowner.html"?>

<para>Right now the <filename class="directory">/tools</filename> directory
is owned by the user <emphasis>lfs</emphasis>, a user that exists only on your
host system. Although you will probably want to delete the
<filename class="directory">/tools</filename> directory once you have
finished your LFS system, you may want to keep it around, for example to
build more LFS systems. But if you keep the
<filename class="directory">/tools</filename> directory as it is, you end up
with files owned by a user ID without a corresponding account. This is
dangerous because a user account created later on could get this same user ID
and would suddenly own the <filename class="directory">/tools</filename>
directory and all the files therein, thus exposing these files to possible
malicious manipulation.</para>

<para>To avoid this issue, you could add the <emphasis>lfs</emphasis> user to
your new LFS system later on when creating the <filename>/etc/passwd</filename>
file, taking care to assign it the same user and group IDs as on your host
system. Alternatively, you can (and the book assumes you do) assign the
contents of the <filename class="directory">/tools</filename> directory to
user <emphasis>root</emphasis> by running the following command:</para>

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

<para>The command uses <parameter>0:0</parameter> instead of <parameter>root:root</parameter>,
because <userinput>chown</userinput> is unable to resolve the name
<quote>root</quote> until the password file has been created.</para>

</sect1>