source: chapter06/changingowner.xml@ 90bfa70

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE section [
  <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>
<section xmlns="http://docbook.org/docbook-ng"
         xml: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>

</section>