ManagingSecurity.xml

   1 <?xml version='1.0' encoding='UTF-8'?><chapter xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US" xml:id="managingsecurity">
   2   <title xml:id="managingsecurity.title">Managing Security in a Lustre File System</title>
   3   <para>This chapter describes security features of the Lustre file system and includes the
   4     following sections:</para>
   5   <itemizedlist>
   6     <listitem>
   7       <para><xref linkend="dbdoclet.50438221_16221"/></para>
   8     </listitem>
   9     <listitem>
  10       <para><xref linkend="dbdoclet.50438221_64726"/></para>
  11     </listitem>
  12   </itemizedlist>
  13   <section xml:id="dbdoclet.50438221_16221">
  14       <title><indexterm><primary>Access Control List (ACL)</primary></indexterm>Using ACLs</title>
  15     <para>An access control list (ACL), is a set of data that informs an operating system about permissions or access rights that each user or group has to specific system objects, such as directories or files. Each object has a unique security attribute that identifies users who have access to it. The ACL lists each object and user access privileges such as read, write or execute.</para>
  16     <section remap="h3">
  17         <title><indexterm><primary>Access Control List (ACL)</primary><secondary>how they work</secondary></indexterm>How ACLs Work</title>
  18       <para>Implementing ACLs varies between operating systems. Systems that support the Portable
  19         Operating System Interface (POSIX) family of standards share a simple yet powerful file
  20         system permission model, which should be well-known to the Linux/UNIX administrator. ACLs
  21         add finer-grained permissions to this model, allowing for more complicated permission
  22         schemes. For a detailed explanation of ACLs on a Linux operating system, refer to the SUSE
  23         Labs article, <emphasis>Posix Access Control Lists on Linux</emphasis>:</para>
  24       <para><link xl:href="http://www.suse.de/~agruen/acl/linux-acls/online/">http://www.suse.de/~agruen/acl/linux-acls/online/</link></para>
  25       <para>We have implemented ACLs according to this model. The Lustre software works with the
  26         standard Linux ACL tools, setfacl, getfacl, and the historical chacl, normally installed
  27         with the ACL package.</para>
  28       <note>
  29         <para>ACL support is a system-range feature, meaning that all clients have ACL enabled or not. You cannot specify which clients should enable ACL.</para>
  30       </note>
  31     </section>
  32     <section remap="h3">
  33         <title><indexterm>
  34           <primary>Access Control List (ACL)</primary>
  35           <secondary>using</secondary>
  36         </indexterm>Using ACLs with the Lustre Software</title>
  37       <para>POSIX Access Control Lists (ACLs) can be used with the Lustre software. An ACL consists
  38         of file entries representing permissions based on standard POSIX file system object
  39         permissions that define three classes of user (owner, group and other). Each class is
  40         associated with a set of permissions [read (r), write (w) and execute (x)].</para>
  41       <itemizedlist>
  42         <listitem>
  43           <para>Owner class permissions define access privileges of the file owner.</para>
  44         </listitem>
  45         <listitem>
  46           <para>Group class permissions define access privileges of the owning group.</para>
  47         </listitem>
  48         <listitem>
  49           <para>Other class permissions define access privileges of all users not in the owner or group class.</para>
  50         </listitem>
  51       </itemizedlist>
  52       <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>
  53       <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>
  54       <para>The MDS needs to be configured to enable ACLs. Use <literal>--mountfsoptions</literal> to enable ACLs when creating your configuration:</para>
  55       <screen>$ mkfs.lustre --fsname spfs --mountfsoptions=acl --mdt -mgs /dev/sda</screen>
  56       <para>Alternately, you can enable ACLs at run time by using the <literal>--acl</literal> option with <literal>mkfs.lustre</literal>:</para>
  57       <screen>$ mount -t lustre -o acl /dev/sda /mnt/mdt</screen>
  58       <para>To check ACLs on the MDS:</para>
  59       <screen>$ lctl get_param -n mdc.home-MDT0000-mdc-*.connect_flags | grep acl acl</screen>
  60       <para>To mount the client with no ACLs:</para>
  61       <screen>$ mount -t lustre -o noacl ibmds2@o2ib:/home /home</screen>
  62       <para>ACLs are enabled in a Lustre file system on a system-wide basis; either all clients
  63         enable ACLs or none do. Activating ACLs is controlled by MDS mount options
  64           <literal>acl</literal> / <literal>noacl</literal> (enable/disable ACLs). Client-side mount
  65         options acl/noacl are ignored. You do not need to change the client configuration, and the
  66         &apos;acl&apos; string will not appear in the client /etc/mtab. The client acl mount option
  67         is no longer needed. If a client is mounted with that option, then this message appears in
  68         the MDS syslog:</para>
  69       <screen>...MDS requires ACL support but client does not</screen>
  70       <para>The message is harmless but indicates a configuration issue, which should be corrected.</para>
  71       <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>
  72     </section>
  73     <section remap="h3">
  74         <title><indexterm><primary>Access Control List (ACL)</primary><secondary>examples</secondary></indexterm>Examples</title>
  75       <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>
  76       <screen>[root@client lustre]# umask 027
  77 [root@client lustre]# mkdir rain
  78 [root@client lustre]# ls -ld rain
  79 drwxr-x---  2 root root 4096 Feb 20 06:50 rain
  80 [root@client lustre]# getfacl rain
  81 # file: rain
  82 # owner: root
  83 # group: root
  84 user::rwx
  85 group::r-x
  86 other::---
  87
  88 [root@client lustre]# setfacl -m user:chirag:rwx rain
  89 [root@client lustre]# ls -ld rain
  90 drwxrwx---+ 2 root root 4096 Feb 20 06:50 rain
  91 [root@client lustre]# getfacl --omit-header rain
  92 user::rwx
  93 user:chirag:rwx
  94 group::r-x
  95 mask::rwx
  96 other::---</screen>
  97     </section>
  98   </section>
  99   <section xml:id="dbdoclet.50438221_64726">
 100     <title><indexterm><primary>root squash</primary></indexterm>Using Root Squash</title>
 101     <para>Root squash is a security feature which restricts super-user access rights to a Lustre
 102       file system. Without the root squash feature enabled, Lustre file system users on untrusted
 103       clients could access or modify files owned by root on the file system, including deleting
 104       them. Using the root squash feature restricts file access/modifications as the root user to
 105       only the specified clients. Note, however, that this does <emphasis>not</emphasis> prevent
 106       users on insecure clients from accessing files owned by <emphasis>other</emphasis>
 107       users.</para>
 108     <para>The root squash feature works by re-mapping the user ID (UID) and group ID (GID) of the
 109       root user to a UID and GID specified by the system administrator, via the Lustre configuration
 110       management server (MGS). The root squash feature also enables the Lustre file system
 111       administrator to specify a set of client for which UID/GID re-mapping does not apply.</para>
 112     <section remap="h3">
 113         <title><indexterm><primary>root squash</primary><secondary>configuring</secondary></indexterm>Configuring Root Squash</title>
 114       <para>Root squash functionality is managed by two configuration parameters, <literal>root_squash</literal> and <literal>nosquash_nids</literal>.</para>
 115       <itemizedlist>
 116         <listitem>
 117           <para>The <literal>root_squash</literal> parameter specifies the UID and GID with which the root user accesses the Lustre file system.</para>
 118         </listitem>
 119         <listitem>
 120           <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="dbdoclet.50438221_48757"/>). For example:</para>
 121         </listitem>
 122       </itemizedlist>
 123       <screen>nosquash_nids=172.16.245.[0-255/2]@tcp</screen>
 124       <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>
 125     </section>
 126     <section xml:id="dbdoclet.50438221_48757">
 127         <title><indexterm><primary>root squash</primary><secondary>enabling</secondary></indexterm>Enabling and Tuning Root Squash</title>
 128       <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>
 129       <para>Root squash parameters can be set when the MDT is created (<literal>mkfs.lustre --mdt</literal>). For example:</para>
 130       <screen>mds# mkfs.lustre --reformat --fsname=testfs --mdt --mgs \
 131        --param &quot;mdt.root_squash=500:501&quot; \
 132        --param &quot;mdt.nosquash_nids=&apos;0@elan1 192.168.1.[10,11]&apos;&quot; /dev/sda1</screen>
 133       <para>Root squash parameters can also be changed on an unmounted device with <literal>tunefs.lustre</literal>. For example:</para>
 134       <screen>tunefs.lustre --param &quot;mdt.root_squash=65534:65534&quot;  \
 135 --param &quot;mdt.nosquash_nids=192.168.0.13@tcp0&quot; /dev/sda1
 136 </screen>
 137       <para>Root squash parameters can also be changed with the <literal>lctl conf_param</literal> command. For example:</para>
 138       <screen>mgs# lctl conf_param testfs.mdt.root_squash=&quot;1000:101&quot;
 139 mgs# lctl conf_param testfs.mdt.nosquash_nids=&quot;*@tcp&quot;</screen>
 140       <note>
 141         <para>When using the lctl conf_param command, keep in mind:</para>
 142         <itemizedlist>
 143           <listitem>
 144             <para><literal>lctl conf_param</literal> must be run on a live MGS</para>
 145           </listitem>
 146           <listitem>
 147             <para><literal>lctl conf_param</literal> causes the parameter to change on all MDSs</para>
 148           </listitem>
 149           <listitem>
 150             <para><literal>lctl conf_param</literal> is to be used once per a parameter</para>
 151           </listitem>
 152         </itemizedlist>
 153       </note>
 154       <para>The <literal>nosquash_nids</literal> list can be cleared with:</para>
 155       <screen>mgs# lctl conf_param testfs.mdt.nosquash_nids=&quot;NONE&quot;</screen>
 156       <para>- OR -</para>
 157       <screen>mgs# lctl conf_param testfs.mdt.nosquash_nids=&quot;clear&quot;</screen>
 158       <para>If the <literal>nosquash_nids</literal> value consists of several NID ranges (e.g. <literal>0@elan</literal>, <literal>1@elan1</literal>), the list of NID ranges must be quoted with single (&apos;) or double (&apos;&apos;) quotation marks. List elements must be separated with a space. For example:</para>
 159       <screen>mds# mkfs.lustre ... --param &quot;mdt.nosquash_nids=&apos;0@elan1 1@elan2&apos;&quot; /dev/sda1
 160 lctl conf_param testfs.mdt.nosquash_nids=&quot;24@elan 15@elan1&quot;</screen>
 161       <para>These are examples of incorrect syntax:</para>
 162       <screen>mds# mkfs.lustre ... --param &quot;mdt.nosquash_nids=0@elan1 1@elan2&quot; /dev/sda1
 163 lctl conf_param testfs.mdt.nosquash_nids=24@elan 15@elan1</screen>
 164       <para>To check root squash parameters, use the lctl get_param command:</para>
 165       <screen>mds# lctl get_param mdt.testfs-MDT0000.root_squash
 166 lctl get_param mdt.*.nosquash_nids</screen>
 167       <note>
 168         <para>An empty nosquash_nids list is reported as NONE.</para>
 169       </note>
 170     </section>
 171     <section remap="h3">
 172         <title><indexterm><primary>root squash</primary><secondary>tips</secondary></indexterm>Tips on Using Root Squash</title>
 173       <para>Lustre configuration management limits root squash in several ways.</para>
 174       <itemizedlist>
 175         <listitem>
 176           <para>The <literal>lctl conf_param</literal> value overwrites the parameter&apos;s previous value. If the new value uses an incorrect syntax, then the system continues with the old parameters and the previously-correct value is lost on remount. That is, be careful doing root squash tuning.</para>
 177         </listitem>
 178         <listitem>
 179           <para><literal>mkfs.lustre</literal> and <literal>tunefs.lustre</literal> do not perform parameter syntax checking. If the root squash parameters are incorrect, they are ignored on mount and the default values are used instead.</para>
 180         </listitem>
 181         <listitem>
 182           <para>Root squash parameters are parsed with rigorous syntax checking. The root_squash parameter should be specified as <literal>&lt;decnum&gt;:&lt;decnum&gt;</literal>. The <literal>nosquash_nids</literal> parameter should follow LNET NID range list syntax.</para>
 183         </listitem>
 184       </itemizedlist>
 185       <para>LNET NID range syntax:</para>
 186       <screen>&lt;nidlist&gt;     :== &lt;nidrange&gt; [ &apos; &apos; &lt;nidrange&gt; ]
 187 &lt;nidrange&gt;   :== &lt;addrrange&gt; &apos;@&apos; &lt;net&gt;
 188 &lt;addrrange&gt;  :== &apos;*&apos; |
 189            &lt;ipaddr_range&gt; |
 190            &lt;numaddr_range&gt;
 191 &lt;ipaddr_range&gt;       :==
 192 &lt;numaddr_range&gt;.&lt;numaddr_range&gt;.&lt;numaddr_range&gt;.&lt;numaddr_range&gt;
 193 &lt;numaddr_range&gt;      :== &lt;number&gt; |
 194                    &lt;expr_list&gt;
 195 &lt;expr_list&gt;  :== &apos;[&apos; &lt;range_expr&gt; [ &apos;,&apos; &lt;range_expr&gt;] &apos;]&apos;
 196 &lt;range_expr&gt; :== &lt;number&gt; |
 197            &lt;number&gt; &apos;-&apos; &lt;number&gt; |
 198            &lt;number&gt; &apos;-&apos; &lt;number&gt; &apos;/&apos; &lt;number&gt;
 199 &lt;net&gt;        :== &lt;netname&gt; | &lt;netname&gt;&lt;number&gt;
 200 &lt;netname&gt;    :== &quot;lo&quot; | &quot;tcp&quot; | &quot;o2ib&quot; | &quot;cib&quot; | &quot;openib&quot; | &quot;iib&quot; |
 201            &quot;vib&quot; | &quot;ra&quot; | &quot;elan&quot; | &quot;gm&quot; | &quot;mx&quot; | &quot;ptl&quot;
 202 &lt;number&gt;     :== &lt;nonnegative decimal&gt; | &lt;hexadecimal&gt;</screen>
 203       <note>
 204         <para>For networks using numeric addresses (e.g. elan), the address range must be specified in the <literal>&lt;numaddr_range&gt;</literal> syntax. For networks using IP addresses, the address range must be in the <literal>&lt;ipaddr_range&gt;</literal>. For example, if elan is using numeric addresses, <literal>1.2.3.4@elan</literal> is incorrect.</para>
 205       </note>
 206     </section>
 207   </section>
 208 </chapter>