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
   4     includes the following sections:</para>
   5   <itemizedlist>
   6     <listitem>
   7       <para><xref linkend="managingSecurity.acl"/></para>
   8     </listitem>
   9     <listitem>
  10       <para><xref linkend="managingSecurity.root_squash"/></para>
  11     </listitem>
  12   </itemizedlist>
  13   <section xml:id="managingSecurity.acl">
  14     <title><indexterm><primary>Access Control List (ACL)</primary></indexterm>
  15     Using ACLs</title>
  16     <para>An access control list (ACL), is a set of data that informs an
  17       operating system about permissions or access rights that each user or
  18       group has to specific system objects, such as directories or files. Each
  19       object has a unique security attribute that identifies users who have
  20       access to it. The ACL lists each object and user access privileges such as
  21       read, write or execute.</para>
  22     <section xml:id="managingSecurity.acl.howItWorks" remap="h3">
  23       <title><indexterm><primary>Access Control List (ACL)</primary><secondary>
  24         how they work</secondary></indexterm>How ACLs Work</title>
  25       <para>Implementing ACLs varies between operating systems. Systems that
  26         support the Portable Operating System Interface (POSIX) family of
  27         standards share a simple yet powerful file system permission model,
  28         which should be well-known to the Linux/UNIX administrator. ACLs add
  29         finer-grained permissions to this model, allowing for more complicated
  30         permission schemes. For a detailed explanation of ACLs on a Linux
  31         operating system, refer to the SUSE Labs article
  32         <link xl:href="http://wiki.lustre.org/images/5/57/PosixAccessControlInLinux.pdf">
  33           Posix Access Control Lists on Linux</link>.</para>
  34       <para>We have implemented ACLs according to this model. The Lustre
  35         software works with the standard Linux ACL tools, setfacl, getfacl, and
  36         the historical chacl, normally installed with the ACL package.</para>
  37       <note>
  38         <para>ACL support is a system-range feature, meaning that all clients
  39           have ACL enabled or not. You cannot specify which clients should
  40           enable ACL.</para>
  41       </note>
  42     </section>
  43     <section xml:id="managingSecurity.acl.using" remap="h3">
  44       <title><indexterm>
  45         <primary>Access Control List (ACL)</primary>
  46         <secondary>using</secondary>
  47       </indexterm>Using ACLs with the Lustre Software</title>
  48       <para>POSIX Access Control Lists (ACLs) can be used with the Lustre
  49         software. An ACL consists of file entries representing permissions based
  50         on standard POSIX file system object permissions that define three
  51         classes of user (owner, group and other). Each class is associated with
  52         a set of permissions [read (r), write (w) and execute (x)].</para>
  53       <itemizedlist>
  54         <listitem>
  55           <para>Owner class permissions define access privileges of the file
  56             owner.</para>
  57         </listitem>
  58         <listitem>
  59           <para>Group class permissions define access privileges of the owning
  60             group.</para>
  61         </listitem>
  62         <listitem>
  63           <para>Other class permissions define access privileges of all users
  64             not in the owner or group class.</para>
  65         </listitem>
  66       </itemizedlist>
  67       <para>The <literal>ls -l</literal> command displays the owner, group, and
  68         other class permissions in the first column of its output (for example,
  69         <literal>-rw-r- --</literal> for a regular file with read and write
  70         access for the owner class, read access for the group class, and no
  71         access for others).</para>
  72       <para>Minimal ACLs have three entries. Extended ACLs have more than the
  73         three entries. Extended ACLs also contain a mask entry and may contain
  74         any number of named user and named group entries.</para>
  75       <para>The MDS needs to be configured to enable ACLs. Use
  76         <literal>--mountfsoptions</literal> to enable ACLs when creating your
  77         configuration:</para>
  78       <screen>$ mkfs.lustre --fsname spfs --mountfsoptions=acl --mdt -mgs /dev/sda</screen>
  79       <para>Alternately, you can enable ACLs at run time by using the
  80         <literal>--acl</literal> option with <literal>mkfs.lustre</literal>:
  81       </para>
  82       <screen>$ mount -t lustre -o acl /dev/sda /mnt/mdt</screen>
  83       <para>To check ACLs on the MDS:</para>
  84       <screen>$ lctl get_param -n mdc.home-MDT0000-mdc-*.connect_flags | grep acl acl</screen>
  85       <para>To mount the client with no ACLs:</para>
  86       <screen>$ mount -t lustre -o noacl ibmds2@o2ib:/home /home</screen>
  87       <para>ACLs are enabled in a Lustre file system on a system-wide basis;
  88         either all clients enable ACLs or none do. Activating ACLs is controlled
  89         by MDS mount options <literal>acl</literal> / <literal>noacl</literal>
  90         (enable/disable ACLs). Client-side mount options acl/noacl are ignored.
  91         You do not need to change the client configuration, and the
  92         &apos;acl&apos; string will not appear in the client /etc/mtab. The
  93         client acl mount option is no longer needed. If a client is mounted with
  94         that option, then this message appears in the MDS syslog:</para>
  95       <screen>...MDS requires ACL support but client does not</screen>
  96       <para>The message is harmless but indicates a configuration issue, which
  97         should be corrected.</para>
  98       <para>If ACLs are not enabled on the MDS, then any attempts to reference
  99         an ACL on a client return an Operation not supported error.</para>
 100     </section>
 101     <section xml:id="managingSecurity.acl.examples" remap="h3">
 102         <title><indexterm>
 103           <primary>Access Control List (ACL)</primary>
 104           <secondary>examples</secondary>
 105         </indexterm>Examples</title>
 106       <para>These examples are taken directly from the POSIX paper referenced
 107         above. ACLs on a Lustre file system work exactly like ACLs on any Linux
 108         file system. They are manipulated with the standard tools in the
 109         standard manner. Below, we create a directory and allow a specific user
 110         access.</para>
 111       <screen>[root@client lustre]# umask 027
 112 [root@client lustre]# mkdir rain
 113 [root@client lustre]# ls -ld rain
 114 drwxr-x---  2 root root 4096 Feb 20 06:50 rain
 115 [root@client lustre]# getfacl rain
 116 # file: rain
 117 # owner: root
 118 # group: root
 119 user::rwx
 120 group::r-x
 121 other::---
 122
 123 [root@client lustre]# setfacl -m user:chirag:rwx rain
 124 [root@client lustre]# ls -ld rain
 125 drwxrwx---+ 2 root root 4096 Feb 20 06:50 rain
 126 [root@client lustre]# getfacl --omit-header rain
 127 user::rwx
 128 user:chirag:rwx
 129 group::r-x
 130 mask::rwx
 131 other::---</screen>
 132     </section>
 133   </section>
 134   <section xml:id="managingSecurity.root_squash">
 135     <title><indexterm>
 136       <primary>root squash</primary>
 137     </indexterm>Using Root Squash</title>
 138     <para>Root squash is a security feature which restricts super-user access
 139       rights to a Lustre file system. Without the root squash feature enabled,
 140       Lustre file system users on untrusted clients could access or modify files
 141       owned by root on the file system, including deleting them. Using the root
 142       squash feature restricts file access/modifications as the root user to
 143       only the specified clients. Note, however, that this does
 144       <emphasis>not</emphasis> prevent users on insecure clients from accessing
 145       files owned by <emphasis>other</emphasis> users.</para>
 146     <para>The root squash feature works by re-mapping the user ID (UID) and
 147       group ID (GID) of the root user to a UID and GID specified by the system
 148       administrator, via the Lustre configuration management server (MGS). The
 149       root squash feature also enables the Lustre file system administrator to
 150       specify a set of client for which UID/GID re-mapping does not apply.
 151     </para>
 152                 <note><para>Nodemaps (<xref linkend="lustrenodemap.title" />) are an
 153                 alternative to root squash, since it also allows root squash on a per-client
 154                 basis.  With UID maps, the clients can even have a local root UID without
 155                 actually having root access to the filesystem itself.</para></note>
 156     <section xml:id="managingSecurity.root_squash.config" remap="h3">
 157       <title><indexterm>
 158         <primary>root squash</primary>
 159         <secondary>configuring</secondary>
 160       </indexterm>Configuring Root Squash</title>
 161       <para>Root squash functionality is managed by two configuration
 162         parameters, <literal>root_squash</literal> and
 163         <literal>nosquash_nids</literal>.</para>
 164       <itemizedlist>
 165         <listitem>
 166           <para>The <literal>root_squash</literal> parameter specifies the UID
 167             and GID with which the root user accesses the Lustre file system.
 168           </para>
 169         </listitem>
 170         <listitem>
 171           <para>The <literal>nosquash_nids</literal> parameter specifies the set
 172             of clients to which root squash does not apply. LNet NID range
 173             syntax is used for this parameter (see the NID range syntax rules
 174             described in <xref linkend="managingSecurity.root_squash"/>). For
 175             example:</para>
 176         </listitem>
 177       </itemizedlist>
 178       <screen>nosquash_nids=172.16.245.[0-255/2]@tcp</screen>
 179       <para>In this example, root squash does not apply to TCP clients on subnet
 180         172.16.245.0 that have an even number as the last component of their IP
 181         address.</para>
 182     </section>
 183     <section xml:id="managingSecurity.root_squash.tuning">
 184       <title><indexterm>
 185         <primary>root squash</primary><secondary>enabling</secondary>
 186       </indexterm>Enabling and Tuning Root Squash</title>
 187       <para>The default value for <literal>nosquash_nids</literal> is NULL,
 188         which means that root squashing applies to all clients. Setting the root
 189         squash UID and GID to 0 turns root squash off.</para>
 190       <para>Root squash parameters can be set when the MDT is created
 191         (<literal>mkfs.lustre --mdt</literal>). For example:</para>
 192       <screen>mds# mkfs.lustre --reformat --fsname=testfs --mdt --mgs \
 193        --param &quot;mdt.root_squash=500:501&quot; \
 194        --param &quot;mdt.nosquash_nids=&apos;0@elan1 192.168.1.[10,11]&apos;&quot; /dev/sda1</screen>
 195       <para>Root squash parameters can also be changed on an unmounted device
 196         with <literal>tunefs.lustre</literal>. For example:</para>
 197       <screen>tunefs.lustre --param &quot;mdt.root_squash=65534:65534&quot;  \
 198 --param &quot;mdt.nosquash_nids=192.168.0.13@tcp0&quot; /dev/sda1
 199 </screen>
 200       <para>Root squash parameters can also be changed with the
 201       <literal>lctl conf_param</literal> command. For example:</para>
 202       <screen>mgs# lctl conf_param testfs.mdt.root_squash=&quot;1000:101&quot;
 203 mgs# lctl conf_param testfs.mdt.nosquash_nids=&quot;*@tcp&quot;</screen>
 204       <para>To retrieve the current root squash parameter settings, the
 205       following <literal>lctl get_param</literal> commands can be used:</para>
 206       <screen>mgs# lctl get_param mdt.*.root_squash
 207 mgs# lctl get_param mdt.*.nosquash_nids</screen>
 208       <note>
 209         <para>When using the lctl conf_param command, keep in mind:</para>
 210         <itemizedlist>
 211           <listitem>
 212             <para><literal>lctl conf_param</literal> must be run on a live MGS
 213             </para>
 214           </listitem>
 215           <listitem>
 216             <para><literal>lctl conf_param</literal> causes the parameter to
 217               change on all MDSs</para>
 218           </listitem>
 219           <listitem>
 220             <para><literal>lctl conf_param</literal> is to be used once per a
 221               parameter</para>
 222           </listitem>
 223         </itemizedlist>
 224       </note>
 225       <para>The root squash settings can also be changed temporarily with
 226       <literal>lctl set_param</literal> or persistently with
 227       <literal>lctl set_param -P</literal>.  For example:</para>
 228       <screen>mgs# lctl set_param mdt.testfs-MDT0000.root_squash="1:0"
 229 mgs# lctl set_param -P mdt.testfs-MDT0000.root_squash="1:0"</screen>
 230       <para>The <literal>nosquash_nids</literal> list can be cleared with:</para>
 231       <screen>mgs# lctl conf_param testfs.mdt.nosquash_nids=&quot;NONE&quot;</screen>
 232       <para>- OR -</para>
 233       <screen>mgs# lctl conf_param testfs.mdt.nosquash_nids=&quot;clear&quot;</screen>
 234       <para>If the <literal>nosquash_nids</literal> value consists of several
 235         NID ranges (e.g. <literal>0@elan</literal>, <literal>1@elan1</literal>),
 236         the list of NID ranges must be quoted with single (&apos;) or double
 237         (&apos;&apos;) quotation marks. List elements must be separated with a
 238         space. For example:</para>
 239       <screen>mds# mkfs.lustre ... --param &quot;mdt.nosquash_nids=&apos;0@elan1 1@elan2&apos;&quot; /dev/sda1
 240 lctl conf_param testfs.mdt.nosquash_nids=&quot;24@elan 15@elan1&quot;</screen>
 241       <para>These are examples of incorrect syntax:</para>
 242       <screen>mds# mkfs.lustre ... --param &quot;mdt.nosquash_nids=0@elan1 1@elan2&quot; /dev/sda1
 243 lctl conf_param testfs.mdt.nosquash_nids=24@elan 15@elan1</screen>
 244       <para>To check root squash parameters, use the lctl get_param command:
 245       </para>
 246       <screen>mds# lctl get_param mdt.testfs-MDT0000.root_squash
 247 lctl get_param mdt.*.nosquash_nids</screen>
 248       <note>
 249         <para>An empty nosquash_nids list is reported as NONE.</para>
 250       </note>
 251     </section>
 252     <section xml:id="managingSecurity.root_squash.tips" remap="h3">
 253         <title><indexterm>
 254           <primary>root squash</primary>
 255           <secondary>tips</secondary>
 256         </indexterm>Tips on Using Root Squash</title>
 257       <para>Lustre configuration management limits root squash in several ways.
 258       </para>
 259       <itemizedlist>
 260         <listitem>
 261           <para>The <literal>lctl conf_param</literal> value overwrites the
 262             parameter&apos;s previous value. If the new value uses an incorrect
 263             syntax, then the system continues with the old parameters and the
 264             previously-correct value is lost on remount. That is, be careful
 265             doing root squash tuning.</para>
 266         </listitem>
 267         <listitem>
 268           <para><literal>mkfs.lustre</literal> and
 269             <literal>tunefs.lustre</literal> do not perform parameter syntax
 270             checking. If the root squash parameters are incorrect, they are
 271             ignored on mount and the default values are used instead.</para>
 272         </listitem>
 273         <listitem>
 274           <para>Root squash parameters are parsed with rigorous syntax checking.
 275             The root_squash parameter should be specified as
 276             <literal>&lt;decnum&gt;:&lt;decnum&gt;</literal>. The
 277             <literal>nosquash_nids</literal> parameter should follow LNet NID
 278             range list syntax.</para>
 279         </listitem>
 280       </itemizedlist>
 281       <para>LNet NID range syntax:</para>
 282       <screen>&lt;nidlist&gt;     :== &lt;nidrange&gt; [ &apos; &apos; &lt;nidrange&gt; ]
 283 &lt;nidrange&gt;   :== &lt;addrrange&gt; &apos;@&apos; &lt;net&gt;
 284 &lt;addrrange&gt;  :== &apos;*&apos; |
 285            &lt;ipaddr_range&gt; |
 286            &lt;numaddr_range&gt;
 287 &lt;ipaddr_range&gt;       :==
 288 &lt;numaddr_range&gt;.&lt;numaddr_range&gt;.&lt;numaddr_range&gt;.&lt;numaddr_range&gt;
 289 &lt;numaddr_range&gt;      :== &lt;number&gt; |
 290                    &lt;expr_list&gt;
 291 &lt;expr_list&gt;  :== &apos;[&apos; &lt;range_expr&gt; [ &apos;,&apos; &lt;range_expr&gt;] &apos;]&apos;
 292 &lt;range_expr&gt; :== &lt;number&gt; |
 293            &lt;number&gt; &apos;-&apos; &lt;number&gt; |
 294            &lt;number&gt; &apos;-&apos; &lt;number&gt; &apos;/&apos; &lt;number&gt;
 295 &lt;net&gt;        :== &lt;netname&gt; | &lt;netname&gt;&lt;number&gt;
 296 &lt;netname&gt;    :== &quot;lo&quot; | &quot;tcp&quot; | &quot;o2ib&quot;
 297            | &quot;ra&quot; | &quot;elan&quot;
 298 &lt;number&gt;     :== &lt;nonnegative decimal&gt; | &lt;hexadecimal&gt;</screen>
 299       <note>
 300         <para>For networks using numeric addresses (e.g. elan), the address
 301           range must be specified in the
 302           <literal>&lt;numaddr_range&gt;</literal> syntax. For networks using
 303           IP addresses, the address range must be in the
 304           <literal>&lt;ipaddr_range&gt;</literal>. For example, if elan is using
 305           numeric addresses, <literal>1.2.3.4@elan</literal> is incorrect.
 306         </para>
 307       </note>
 308     </section>
 309   </section>
 310 </chapter>