<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>To check ACLs on the MDS, check that the <literal>acl</literal>
+ connect flag is listed (default since Lustre 1.8):</para>
+ <screen>
+# lctl get_param -n mdc.home-MDT0000-mdc-*.connect_flags | grep acl
+ </screen>
+ <para>ACLs are enabled by default on a Lustre file system, and are
+ controlled 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> to enable or disable
+ ACLs, respectively. You do not need to change the client
+ configuration, and the <literal>acl</literal> string will not appear
+ in the client mount options in <literal>/etc/mtab</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>
+ an ACL on a client return an <literal>Operation not supported</literal>
+ error.
+ </para>
</section>
<section xml:id="managingSecurity.acl.examples" remap="h3">
<title><indexterm>
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
+ <screen>[phil@client lustre]$ umask 027
+[phil@client lustre]$ mkdir rain
+[phil@client lustre]$ ls -ld rain
+drwxr-x--- 2 phil dev 4096 Feb 20 06:50 rain
+[phil@client lustre]$ getfacl rain
# file: rain
-# owner: root
-# group: root
+# owner: phil
+# group: dev
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
+[phil@client lustre]$ setfacl -m user:chirag:rwx rain
+[phil@client lustre]$ ls -ld rain
+drwxrwx---+ 2 phil dev 4096 Feb 20 06:50 rain
+[phil@client lustre]$ getfacl --omit-header rain
user::rwx
user:chirag:rwx
group::r-x
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>
+ squash feature restricts file access/modifications as the root user.
+ Note, however, that this does <emphasis>not</emphasis> prevent users
+ 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.
+ administrator. The preferred way to configure root squash is via nodemaps
+ and the <literal>admin</literal> property. Nodemaps allow root squash on a
+ per-client basis. With UID maps, the clients can even have a local root
+ UID without actually having root access to the filesystem itself.
+ </para>
+ <para>Please refer to explanations about the <literal>admin</literal>
+ property in the chapter dedicated to Nodemaps, in
+ <xref linkend="lustrenodemap.alteringproperties.managing" />.
</para>
- <note><para>Nodemaps (<xref linkend="lustrenodemap.title" />) are an
- alternative to root squash, since it also allows root squash on a per-client
- basis. With UID maps, the clients can even have a local root UID without
- actually having root access to the filesystem itself.</para></note>
- <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
-</screen>
- <para>Root squash parameters can also be changed with the
- <literal>lctl conf_param</literal> command. For example:</para>
- <screen>mgs# lctl conf_param testfs.mdt.root_squash="1000:101"
-mgs# lctl conf_param testfs.mdt.nosquash_nids="*@tcp"</screen>
- <para>To retrieve the current root squash parameter settings, the
- following <literal>lctl get_param</literal> commands can be used:</para>
- <screen>mgs# lctl get_param mdt.*.root_squash
-mgs# lctl get_param mdt.*.nosquash_nids</screen>
- <note>
- <para>When using the lctl conf_param command, keep in mind:</para>
- <itemizedlist>
- <listitem>
- <para><literal>lctl conf_param</literal> must be run on a live MGS
- </para>
- </listitem>
- <listitem>
- <para><literal>lctl conf_param</literal> causes the parameter to
- change on all MDSs</para>
- </listitem>
- <listitem>
- <para><literal>lctl conf_param</literal> is to be used once per a
- parameter</para>
- </listitem>
- </itemizedlist>
- </note>
- <para>The root squash settings can also be changed temporarily with
- <literal>lctl set_param</literal> or persistently with
- <literal>lctl set_param -P</literal>. For example:</para>
- <screen>mgs# lctl set_param mdt.testfs-MDT0000.root_squash="1:0"
-mgs# lctl set_param -P mdt.testfs-MDT0000.root_squash="1:0"</screen>
- <para>The <literal>nosquash_nids</literal> list can be cleared with:</para>
- <screen>mgs# lctl conf_param testfs.mdt.nosquash_nids="NONE"</screen>
- <para>- OR -</para>
- <screen>mgs# lctl conf_param testfs.mdt.nosquash_nids="clear"</screen>
- <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 (') or double
- ('') quotation marks. List elements must be separated with a
- space. For example:</para>
- <screen>mds# mkfs.lustre ... --param "mdt.nosquash_nids='0@elan1 1@elan2'" /dev/sda1
-lctl conf_param testfs.mdt.nosquash_nids="24@elan 15@elan1"</screen>
- <para>These are examples of incorrect syntax:</para>
- <screen>mds# mkfs.lustre ... --param "mdt.nosquash_nids=0@elan1 1@elan2" /dev/sda1
-lctl conf_param testfs.mdt.nosquash_nids=24@elan 15@elan1</screen>
- <para>To check root squash parameters, use the lctl get_param command:
- </para>
- <screen>mds# lctl get_param mdt.testfs-MDT0000.root_squash
-lctl get_param mdt.*.nosquash_nids</screen>
- <note>
- <para>An empty nosquash_nids list is reported as NONE.</para>
- </note>
- </section>
- <section xml:id="managingSecurity.root_squash.tips" remap="h3">
- <title><indexterm>
- <primary>root squash</primary>
- <secondary>tips</secondary>
- </indexterm>Tips on Using Root Squash</title>
- <para>Lustre configuration management limits root squash in several ways.
- </para>
- <itemizedlist>
- <listitem>
- <para>The <literal>lctl conf_param</literal> value overwrites the
- parameter'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>
- </listitem>
- <listitem>
- <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>
- </listitem>
- <listitem>
- <para>Root squash parameters are parsed with rigorous syntax checking.
- The root_squash parameter should be specified as
- <literal><decnum>:<decnum></literal>. The
- <literal>nosquash_nids</literal> parameter should follow LNet NID
- range list syntax.</para>
- </listitem>
- </itemizedlist>
- <para>LNet NID range syntax:</para>
- <screen><nidlist> :== <nidrange> [ ' ' <nidrange> ]
-<nidrange> :== <addrrange> '@' <net>
-<addrrange> :== '*' |
- <ipaddr_range> |
- <numaddr_range>
-<ipaddr_range> :==
-<numaddr_range>.<numaddr_range>.<numaddr_range>.<numaddr_range>
-<numaddr_range> :== <number> |
- <expr_list>
-<expr_list> :== '[' <range_expr> [ ',' <range_expr>] ']'
-<range_expr> :== <number> |
- <number> '-' <number> |
- <number> '-' <number> '/' <number>
-<net> :== <netname> | <netname><number>
-<netname> :== "lo" | "tcp" | "o2ib"
- | "ra" | "elan"
-<number> :== <nonnegative decimal> | <hexadecimal></screen>
- <note>
- <para>For networks using numeric addresses (e.g. elan), the address
- range must be specified in the
- <literal><numaddr_range></literal> syntax. For networks using
- IP addresses, the address range must be in the
- <literal><ipaddr_range></literal>. For example, if elan is using
- numeric addresses, <literal>1.2.3.4@elan</literal> is incorrect.
- </para>
- </note>
- </section>
</section>
<section xml:id="managingSecurity.isolation">
<title><indexterm><primary>Isolation</primary></indexterm>
<listitem><para>DAX (Direct Access) is not supported on encrypted
files.</para>
</listitem>
+ <listitem><para condition='l2F'>The st_size of an encrypted
+ symlink will not necessarily give the length of the symlink
+ target as required by POSIX. It will actually give the length of
+ the ciphertext, which will be slightly longer than the plaintext
+ due to NUL-padding and an extra 2-byte overhead.</para>
+ </listitem>
+ <listitem><para condition='l2F'>The maximum length of an encrypted
+ symlink is 2 bytes shorter than the maximum length of an
+ unencrypted symlink.</para>
+ </listitem>
<listitem><para><literal>mmap</literal> is supported. This is
possible because the pagecache for an encrypted file contains
the plaintext, not the ciphertext.</para>
<literal>stat()</literal>.</para>
</listitem>
<listitem>
- <para>Directories may be listed, and the whole namespace tree
- may be walked through.
- </para>
+ <para condition='l2F'>Directories may be listed, in which case
+ the filenames will be listed in an encoded form derived from
+ their ciphertext. The algorithm is subject to change but it is
+ guaranteed that the presented filenames will be no longer than
+ NAME_MAX bytes, will not contain the <literal>/</literal> or
+ <literal>\0</literal> characters, and will uniquely identify
+ directory entries. The <literal>.</literal> and
+ <literal>..</literal> directory entries are special. They are
+ always present and are not encrypted or encoded.</para>
</listitem>
<listitem>
<para>Files may be deleted. That is, nondirectory files may be
content encryption mode will be taken into account, and filename
encryption mode will be ignored to leave filenames in clear text.</para>
</warning>
+ <warning><para condition='l2F'>When Lustre client is built against the
+ embedded kernel library instead of the in-kernel fscrypt, the ability to
+ encrypt file and directory names is governed by new llite parameter named
+ <literal>enable_filename_encryption</literal>, introduced in 2.15, and
+ set to 0 by default.
+ When this parameter is 0, new empty directories configured as encrypted
+ use content encryption only, and not name encryption. This mode is
+ inherited for all subdirectories and files.
+ When <literal>enable_filename_encryption</literal> parameter is set to 1,
+ new empty directories configured as encrypted use full encryption
+ capabilities by encrypting file content and also file and directory
+ names. This mode is inherited for all subdirectories and files.
+ To set the <literal>enable_filename_encryption</literal> parameter
+ globally for all clients, one can do on the MGS:
+<screen>mgs# lctl set_param -P llite.*.enable_filename_encryption=1</screen>
+ Be aware that the <literal>enable_filename_encryption</literal> tuning
+ parameter is not available when Lustre client is built against in-kernel
+ fscrypt. Indeed, the in-kernel fscrypt library always encrypts file name
+ along with file content.<literallayout></literallayout>
+ Also note that new files and directories under a parent encrypted
+ directory created with Lustre 2.14 will not have their names encrypted.
+ Also, because files created with Lustre 2.14 did not have their names
+ encrypted, they will remain so after upgrade to 2.15. To benefit from
+ name encryption for an old directory previously created with Lustre 2.14,
+ you need to do the following after upgrade to 2.15 is complete:
+ <orderedlist>
+ <listitem>
+ <para>create a new encrypted directory. This can use an already
+ existing protector.</para>
+ </listitem>
+ <listitem>
+ <para>unlock the old encrypted directory.</para>
+ </listitem>
+ <listitem>
+ <para>copy all files and directories recursively from the old
+ encrypted directory to the newly created encrypted directory. Note
+ that this operation will re-encrypt all files contents in addition
+ to names.</para>
+ </listitem>
+ <listitem>
+ <para>remove the old encrypted directory.</para>
+ </listitem>
+ </orderedlist>
+ </para>
+ </warning>
</section>
<section xml:id="managingSecurity.clientencryption.threatmodel" remap="h3">
<title><indexterm><primary>encryption threat model</primary>
git://git.whamcloud.com / doc / manual.git / blobdiff