- <section remap="h2">
- <title>22.2 <anchor xml:id="dbdoclet.50438221_64726" xreflabel=""/>Using <anchor xml:id="dbdoclet.50438221_marker-1294644" xreflabel=""/>Root Squash</title>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296220" xreflabel=""/>Lustre 1.6 introduced root squash functionality, a security feature which controls super user access rights to an Lustre file system. Before the root squash feature was added, Lustre users could run rm -rf * as root, and remove data which should not be deleted. Using the root squash feature prevents this outcome.</para>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296221" xreflabel=""/>The root squash feature works by re-mapping the user ID (UID) and group ID (GID) of the root user to a UID and GID specified by the system administrator, via the Lustre configuration management server (MGS). The root squash feature also enables the Lustre administrator to specify a set of client for which UID/GID re-mapping does not apply.</para>
- <section remap="h3">
- <title><anchor xml:id="dbdoclet.50438221_pgfId-1292937" xreflabel=""/>22.2.1 Configuring <anchor xml:id="dbdoclet.50438221_marker-1294610" xreflabel=""/>Root Squash</title>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296229" xreflabel=""/>Root squash functionality is managed by two configuration parameters, root_squash and nosquash_nids.</para>
- <itemizedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296230" xreflabel=""/> The root_squash parameter specifies the UID and GID with which the root user accesses the Lustre file system.</para>
- </listitem>
-<listitem>
- <para> </para>
- </listitem>
-<listitem>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296231" xreflabel=""/> The nosquash_nids parameter specifies the set of clients to which root squash does not apply. LNET NID range syntax is used for this parameter (see the NID range syntax rules described in <link xl:href="ManagingSecurity.html#50438221_48757">Enabling and Tuning Root Squash</link>). For example:</para>
- </listitem>
-<listitem>
- <para> </para>
- </listitem>
-</itemizedlist>
- <screen><anchor xml:id="dbdoclet.50438221_pgfId-1296235" xreflabel=""/>nosquash_nids=172.16.245.[0-255/2]@tcp
-</screen>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296236" xreflabel=""/>In this example, root squash does not apply to TCP clients on subnet 172.16.245.0 that have an even number as the last component of their IP address.</para>
- </section>
- <section remap="h3">
- <title><anchor xml:id="dbdoclet.50438221_pgfId-1292749" xreflabel=""/>22.2.2 <anchor xml:id="dbdoclet.50438221_48757" xreflabel=""/>Enabling and <anchor xml:id="dbdoclet.50438221_marker-1294611" xreflabel=""/>Tuning Root Squash</title>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296245" xreflabel=""/>The default value for nosquash_nids is NULL, which means that root squashing applies to all clients. Setting the root squash UID and GID to 0 turns root squash off.</para>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296246" xreflabel=""/>Root squash parameters can be set when the MDT is created (mkfs.lustre --mdt). For example:</para>
- <screen><anchor xml:id="dbdoclet.50438221_pgfId-1296247" xreflabel=""/>mkfs.lustre --reformat --fsname=Lustre --mdt --mgs \
-<anchor xml:id="dbdoclet.50438221_pgfId-1296248" xreflabel=""/> --param "mds.root_squash=500:501" \
-<anchor xml:id="dbdoclet.50438221_pgfId-1296249" xreflabel=""/> --param "mds.nosquash_nids='0@elan1 192.168.1.[10,11]'" /dev/sda1
-</screen>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296250" xreflabel=""/>Root squash parameters can also be changed on an unmounted device with tunefs.lustre. For example:</para>
- <screen><anchor xml:id="dbdoclet.50438221_pgfId-1296251" xreflabel=""/>tunefs.lustre --param "mds.root_squash=65534:65534" \
-<anchor xml:id="dbdoclet.50438221_pgfId-1296252" xreflabel=""/>--param "mds.nosquash_nids=192.168.0.13@tcp0" /dev/sda1
-</screen>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296253" xreflabel=""/>Root squash parameters can also be changed with the lctl conf_param command. For example:</para>
- <screen><anchor xml:id="dbdoclet.50438221_pgfId-1296254" xreflabel=""/>lctl conf_param Lustre.mds.root_squash="1000:100"
-<anchor xml:id="dbdoclet.50438221_pgfId-1296255" xreflabel=""/>lctl conf_param Lustre.mds.nosquash_nids="*@tcp"
-</screen>
- <informaltable frame="none">
- <tgroup cols="1">
- <colspec colname="c1" colwidth="100*"/>
- <tbody>
- <row>
- <entry><para><emphasis role="bold">Note -</emphasis><anchor xml:id="dbdoclet.50438221_pgfId-1296256" xreflabel=""/>When using the lctl conf_param command, keep in mind:</para><para> * lctl conf_param must be run on a live MGS</para><para> * lctl conf_param causes the parameter to change on all MDSs</para><para> * lctl conf_param is to be used once per a parameter</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296271" xreflabel=""/>The nosquash_nids list can be cleared with:</para>
- <screen><anchor xml:id="dbdoclet.50438221_pgfId-1296272" xreflabel=""/>lctl conf_param Lustre.mds.nosquash_nids="NONE"
-</screen>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296273" xreflabel=""/>- OR -</para>
- <screen><anchor xml:id="dbdoclet.50438221_pgfId-1296274" xreflabel=""/>lctl conf_param Lustre.mds.nosquash_nids="clear"
-</screen>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296275" xreflabel=""/>If the nosquash_nids value consists of several NID ranges (e.g. 0@elan, 1@elan1), the list of NID ranges must be quoted with single (') or double ('') quotation marks. List elements must be separated with a space. For example:</para>
- <screen><anchor xml:id="dbdoclet.50438221_pgfId-1296276" xreflabel=""/>mkfs.lustre ... --param "mds.nosquash_nids='0@elan1 1@elan2'" /dev/sda1
-<anchor xml:id="dbdoclet.50438221_pgfId-1296277" xreflabel=""/>lctl conf_param Lustre.mds.nosquash_nids="24@elan 15@elan1"
-</screen>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296278" xreflabel=""/>These are examples of incorrect syntax:</para>
- <screen><anchor xml:id="dbdoclet.50438221_pgfId-1296279" xreflabel=""/>mkfs.lustre ... --param "mds.nosquash_nids=0@elan1 1@elan2" /dev/sda1
-<anchor xml:id="dbdoclet.50438221_pgfId-1296280" xreflabel=""/>lctl conf_param Lustre.mds.nosquash_nids=24@elan 15@elan1
-</screen>
- <para><anchor xml:id="dbdoclet.50438221_pgfId-1296281" xreflabel=""/>To check root squash parameters, use the lctl get_param command:</para>
- <screen><anchor xml:id="dbdoclet.50438221_pgfId-1296282" xreflabel=""/>lctl get_param mds.Lustre-MDT0000.root_squash
-<anchor xml:id="dbdoclet.50438221_pgfId-1296283" xreflabel=""/>lctl get_param mds.Lustre-MDT000*.nosquash_nids
+ <section xml:id="managingSecurity.acl.using" remap="h3">
+ <title><indexterm>
+ <primary>Access Control List (ACL)</primary>
+ <secondary>using</secondary>
+ </indexterm>Using ACLs with the Lustre Software</title>
+ <para>POSIX Access Control Lists (ACLs) can be used with the Lustre
+ software. An ACL consists of file entries representing permissions based
+ on standard POSIX file system object permissions that define three
+ classes of user (owner, group and other). Each class is associated with
+ a set of permissions [read (r), write (w) and execute (x)].</para>
+ <itemizedlist>
+ <listitem>
+ <para>Owner class permissions define access privileges of the file
+ owner.</para>
+ </listitem>
+ <listitem>
+ <para>Group class permissions define access privileges of the owning
+ group.</para>
+ </listitem>
+ <listitem>
+ <para>Other class permissions define access privileges of all users
+ not in the owner or group class.</para>
+ </listitem>
+ </itemizedlist>
+ <para>The <literal>ls -l</literal> command displays the owner, group, and
+ other class permissions in the first column of its output (for example,
+ <literal>-rw-r- --</literal> for a regular file with read and write
+ access for the owner class, read access for the group class, and no
+ access for others).</para>
+ <para>Minimal ACLs have three entries. Extended ACLs have more than the
+ three entries. Extended ACLs also contain a mask entry and may contain
+ any number of named user and named group entries.</para>
+ <para>The MDS needs to be configured to enable ACLs. Use
+ <literal>--mountfsoptions</literal> to enable ACLs when creating your
+ configuration:</para>
+ <screen>$ mkfs.lustre --fsname spfs --mountfsoptions=acl --mdt -mgs /dev/sda</screen>
+ <para>Alternately, you can enable ACLs at run time by using the
+ <literal>--acl</literal> option with <literal>mkfs.lustre</literal>:
+ </para>
+ <screen>$ mount -t lustre -o acl /dev/sda /mnt/mdt</screen>
+ <para>To check ACLs on the MDS:</para>
+ <screen>$ lctl get_param -n mdc.home-MDT0000-mdc-*.connect_flags | grep acl acl</screen>
+ <para>To mount the client with no ACLs:</para>
+ <screen>$ mount -t lustre -o noacl ibmds2@o2ib:/home /home</screen>
+ <para>ACLs are enabled in a Lustre file system on a system-wide basis;
+ either all clients enable ACLs or none do. Activating ACLs is controlled
+ by MDS mount options <literal>acl</literal> / <literal>noacl</literal>
+ (enable/disable ACLs). Client-side mount options acl/noacl are ignored.
+ You do not need to change the client configuration, and the
+ 'acl' string will not appear in the client /etc/mtab. The
+ client acl mount option is no longer needed. If a client is mounted with
+ that option, then this message appears in the MDS syslog:</para>
+ <screen>...MDS requires ACL support but client does not</screen>
+ <para>The message is harmless but indicates a configuration issue, which
+ should be corrected.</para>
+ <para>If ACLs are not enabled on the MDS, then any attempts to reference
+ an ACL on a client return an Operation not supported error.</para>
+ </section>
+ <section xml:id="managingSecurity.acl.examples" remap="h3">
+ <title><indexterm>
+ <primary>Access Control List (ACL)</primary>
+ <secondary>examples</secondary>
+ </indexterm>Examples</title>
+ <para>These examples are taken directly from the POSIX paper referenced
+ above. ACLs on a Lustre file system work exactly like ACLs on any Linux
+ file system. They are manipulated with the standard tools in the
+ standard manner. Below, we create a directory and allow a specific user
+ access.</para>
+ <screen>[root@client lustre]# umask 027
+[root@client lustre]# mkdir rain
+[root@client lustre]# ls -ld rain
+drwxr-x--- 2 root root 4096 Feb 20 06:50 rain
+[root@client lustre]# getfacl rain
+# file: rain
+# owner: root
+# group: root
+user::rwx
+group::r-x
+other::---
+
+[root@client lustre]# setfacl -m user:chirag:rwx rain
+[root@client lustre]# ls -ld rain
+drwxrwx---+ 2 root root 4096 Feb 20 06:50 rain
+[root@client lustre]# getfacl --omit-header rain
+user::rwx
+user:chirag:rwx
+group::r-x
+mask::rwx
+other::---</screen>
+ </section>
+ </section>
+ <section xml:id="managingSecurity.root_squash">
+ <title><indexterm>
+ <primary>root squash</primary>
+ </indexterm>Using Root Squash</title>
+ <para>Root squash is a security feature which restricts super-user access
+ rights to a Lustre file system. Without the root squash feature enabled,
+ Lustre file system users on untrusted clients could access or modify files
+ owned by root on the file system, including deleting them. Using the root
+ squash feature restricts file access/modifications as the root user to
+ only the specified clients. Note, however, that this does
+ <emphasis>not</emphasis> prevent users on insecure clients from accessing
+ files owned by <emphasis>other</emphasis> users.</para>
+ <para>The root squash feature works by re-mapping the user ID (UID) and
+ group ID (GID) of the root user to a UID and GID specified by the system
+ administrator, via the Lustre configuration management server (MGS). The
+ root squash feature also enables the Lustre file system administrator to
+ specify a set of client for which UID/GID re-mapping does not apply.
+ </para>
+ <section xml:id="managingSecurity.root_squash.config" remap="h3">
+ <title><indexterm>
+ <primary>root squash</primary>
+ <secondary>configuring</secondary>
+ </indexterm>Configuring Root Squash</title>
+ <para>Root squash functionality is managed by two configuration
+ parameters, <literal>root_squash</literal> and
+ <literal>nosquash_nids</literal>.</para>
+ <itemizedlist>
+ <listitem>
+ <para>The <literal>root_squash</literal> parameter specifies the UID
+ and GID with which the root user accesses the Lustre file system.
+ </para>
+ </listitem>
+ <listitem>
+ <para>The <literal>nosquash_nids</literal> parameter specifies the set
+ of clients to which root squash does not apply. LNet NID range
+ syntax is used for this parameter (see the NID range syntax rules
+ described in <xref linkend="managingSecurity.root_squash"/>). For
+ example:</para>
+ </listitem>
+ </itemizedlist>
+ <screen>nosquash_nids=172.16.245.[0-255/2]@tcp</screen>
+ <para>In this example, root squash does not apply to TCP clients on subnet
+ 172.16.245.0 that have an even number as the last component of their IP
+ address.</para>
+ </section>
+ <section xml:id="managingSecurity.root_squash.tuning">
+ <title><indexterm>
+ <primary>root squash</primary><secondary>enabling</secondary>
+ </indexterm>Enabling and Tuning Root Squash</title>
+ <para>The default value for <literal>nosquash_nids</literal> is NULL,
+ which means that root squashing applies to all clients. Setting the root
+ squash UID and GID to 0 turns root squash off.</para>
+ <para>Root squash parameters can be set when the MDT is created
+ (<literal>mkfs.lustre --mdt</literal>). For example:</para>
+ <screen>mds# mkfs.lustre --reformat --fsname=testfs --mdt --mgs \
+ --param "mdt.root_squash=500:501" \
+ --param "mdt.nosquash_nids='0@elan1 192.168.1.[10,11]'" /dev/sda1</screen>
+ <para>Root squash parameters can also be changed on an unmounted device
+ with <literal>tunefs.lustre</literal>. For example:</para>
+ <screen>tunefs.lustre --param "mdt.root_squash=65534:65534" \
+--param "mdt.nosquash_nids=192.168.0.13@tcp0" /dev/sda1