| Lustre 1.6 Operations Manual |    
|
| C H A P T E R 25 |
|
Lustre Security |
This chapter describes Lustre security and includes the following section:
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.
Implementing ACLs varies between operating systems. Systems that support the Portable Operating System Interface (POSIX) family of standards share a simple yet powerful file system permission model, which should be well-known to the Linux/Unix administrator. ACLs add finer-grained permissions to this model, allowing for more complicated permission schemes. For a detailed explanation of ACLs on Linux, refer to the SuSE Labs article, Posix Access Control Lists on Linux:
http://www.suse.de/~agruen/acl/linux-acls/online/
We have implemented ACLs according to this model. Lustre supports the standard Linux ACL tools, setfacl, getfacl, and the historical chacl, normally installed with the ACL package.
| Note - ACL support is a system-range feature, meaning that all clients have ACL enabled or not. You cannot specify which clients should enable ACL. |
Lustre supports POSIX Access Control Lists (ACLs). 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)].
The ls -l command displays the owner, group, and other class permissions in the first column of its output (for example, -rw-r- -- for a regular file with read and write access for the owner class, read access for the group class, and no access for others).
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.
Lustre ACL support depends on the MDS, which needs to be configured to enable ACLs. Use --mountfsoptions to enable ACL support when creating your configuration:
$ mkfs.lustre --fsname spfs --mountfsoptions=acl --mdt -mgs /dev/sda
Alternately, you can enable ACLs at run time by using the --acl option with mkfs.lustre:
$ mount -t lustre -o acl /dev/sda /mnt/mdt
$ lctl get_param -n mdc.home-MDT0000-mdc-*.connect_flags | grep acl acl
To mount the client with no ACLs:
$ mount -t lustre -o noacl ibmds2@o2ib:/home /home
Lustre ACL support is a system-wide feature; either all clients enable ACLs or none do. Activating ACLs is controlled by MDS mount options acl / noacl (enable/disableACLs). 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:
...MDS requires ACL support but client does not
The message is harmless but indicates a configuration issue, which should be corrected.
If ACLs are not enabled on the MDS, then any attempts to reference an ACL on a client return an Operation not supported error.
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.
[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-heade rain user::rwx user:chirag:rwx group::r-x mask::rwx other::---
Lustre 1.6 introduces 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.
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 Lusre cofiguration 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.
Root squash functionality is managed by two configuration parameters, root_squash and nosquash_nids.
nosquash_nids=172.16.245.[0-255/2]@tcp
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.
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.
Root squash parameters can be set when the MDT is created (mkfs.lustre --mdt). For example:
mkfs.lustre --reformat --fsname=Lustre --mdt --mgs \ --param "mdt.root_squash=500:501" \ --param "mdt.nosquash_nids='0@elan1 192.168.1.[10,11]'" /dev/sda1
Root squash parameters can also be changed on an unmounted device with tunefs.lustre. For example:
tunefs.lustre --param "mdt.root_squash=65534:65534" \ --param "mdt.nosquash_nids=192.168.0.13@tcp0" /dev/sda1
Root squash parameters can also be changed with the lctl conf_param command. For example:
lctl conf_param Lustre.mdt.root_squash="1000:100" lctl conf_param Lustre.mdt.nosquash_nids="*@tcp"
The nosquash_nids list can be cleared with:
lctl conf_param Lustre.mdt.nosquash_nids="NONE"
lctl conf_param Lustre.mdt.nosquash_nids="clear"
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:
mkfs.lustre ... --param "mdt.nosquash_nids='0@elan1 1@elan2'" /dev/sda1 lctl conf_param Lustre.mdt.nosquash_nids="24@elan 15@elan1"
These are examples of incorrect syntax:
mkfs.lustre ... --param "mdt.nosquash_nids=0@elan1 1@elan2" /dev/sda1 lctl conf_param Lustre.mdt.nosquash_nids=24@elan 15@elan1
To check root squash parameters, use the lctl get_param command:
lctl get_param mdt.Lustre-MDT0000.root_squash lctl get_param mdt.Lustre-MDT000*.nosquash_nids
| Note - An empty nosquash_nids list is reported as NONE. |
Lustre configuration management limits root squash in several ways.
<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" | "cib" | "openib" | "iib" | "vib" | "ra" | "elan" | "gm" | "mx" | "ptl" <number> :== <nonnegative decimal> | <hexadecimal>
| Lustre 1.6 Operations Manual | 820-3681-11 |
|
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.