Follow

File permissions and ACLs on the Pan cluster

This article describes the mechanisms we use on the Pan cluster to control user access to and privileges with files and directories, and answers a few common questions about how you can use these mechanisms effectively.

UNIX file permissions

We use UNIX file permissions as a simple and straightforward way of controlling who may do what with a file or directory. The UNIX file permission model has three operations that can be done, namely, read (r), write (w) and execute (x), and three groups of people that can be given permission: an owner (u, short for user); a single UNIX group (g), which may or may not have the owner as a member; and everyone else (o, short for others), often referred to as the world.

How do I find out the UNIX permissions on a file or directory?

Run the following command:

ls -l file

The output will look something like this:

-rwxr-xr-x. 1 jblo123 nesi 775 Jan  6  2014 file*

The first field (-rwxr-xr-x.) represents the file's permissions. On the Pan cluster, it contains 11 characters:

  • The first character represents the type of the file: d for a directory, l for a symbolic link, or - for an ordinary file.
  • The second, third and fourth characters are the permissions of the file's owner. In this case, the owner can read, write and execute the file.
  • The fifth, sixth and seventh characters are the permissions of the file's group. In this case, members of the group can read and execute the file, but are not allowed to write to it.
  • The eigth, ninth and tenth characters are the permissions of the world: that is, of everyone who is neither the owner, nor a member of the group, nor otherwise provided for in the file's access control list. In this case, the world can read and execute the file, but may not write to it.
  • The eleventh character indicates the presence or absence of an access control list.

What do strange characters like s and t in the permissions field mean?

  • If the fourth character is a lower-case s, the file or directory is executable by its owner and its setuid bit is set.
  • If the fourth character is a capital S, the setuid bit is set but the file or directory is not executable by its owner. This is an unusual situation that is probably not intended by the owner and may cause problems.
  • If the seventh character is a lower-case s, the file or directory is executable by members of its group and its setgid bit is set.
  • If the seventh character is a capital S, the setgid bit is set but the file or directory is not executable by members of its group. This is also an unusual situation, and merits investigation if group members complain of not being able to browse and use the directory effectively.
  • If the tenth character is a lower-case t, the file or directory is executable by the world and its sticky bit is set.
  • If the tenth character is an capital T, the sticky bit is set but the file or directory is not executable by the world.

How do I change the owner of a file or directory?

Contact the support team at support@nesi.org.nz.

You will almost certainly be prevented from using the chown command, as only the super-user has the required permissions in most situations.

How do I change the group of a file or directory?

Use the chgrp command:

chgrp new_group file.txt

If you are operating on a directory, you may wish to use chgrp -R to apply the change to the directory's contents recursively. If you intend to change the group of a symbolic link (as opposed to the link's target), you will need to use chgrp -h. It is possible to combine the -R and -h flags.

How do I change the permissions of a file or directory?

Use the chmod command. As with chgrp, you can run chmod recursively by using the -R switch, and you can apply it to a symbolic link by using the -h switch.

For example:

  • To make file.exe executable: chmod +x file.exe
  • To make file.txt non-executable: chmod -x file.txt
  • To make file.txt writable only by its owner and readable only by its owner or a member of its group: chmod go-w,o-r file.txt

Do I need to have execute permissions on a directory in order to use it?

Yes. If you have execute permissions, you can cd into or through the directory; create, delete and rename its immediate contents if you also have write permissions; and get a long listing (ls -l) of its contents. If you don't have execute permissions, you will not be able to do very much with the directory except maybe get a bare list, from outside the directory, of what's in it.

If you need to access a directory but don't have permission to do so, please contact the directory's owner, or send an email to support@nesi.org.nz. Please note that if you approach our support team, we will in most circumstances have to get the consent of the directory owner before giving you access.

I own a file in someone else's directory. What can he or she do with it?

Anyone who has both write and execute permissions on a directory (which almost always includes the directory owner, and may include the directory's group or even the world) can delete or rename any file in that directory, unless the directory's sticky bit is set. Even if the sticky bit is set, the directory owner can still delete or rename the file.

Someone else owns a file in my directory. What can I do with it?

Unless you've set the directory so that either you can't write to it or you can't execute it, you can remove, rename, or edit any file in the directory, even if the file is owned by someone else. Normally, if you edit the file, you will end up owning it.

Please be aware that only some programs can be used to edit a file that you don't own. However, if you need to modify the data, you can always take a copy of the file and edit the copy (which you will automatically own), unless its owner has chosen to take away your read permissions.

Even if you can't read the file, you can still rename or delete it, as these operations only require that you have write and execute permissions in respect of the directory, not in respect of the file itself.

Can I set a file's permissions so that it can be changed but not deleted?

You can't do this for an individual file, but you can (within certain limits) for all the files in a particular directory. There's an option called the sticky bit, which you can set for a directory by running the following command:

chmod +t /path/to/directory

Once the sticky bit is set on a directory, no file in that directory can be deleted or renamed except by the owner of the file, the owner of the directory, or the root user.

However, setting the permissions in this way protects only the file (its name and where it lives), not its contents.

Can I set a file's permissions so that it can be deleted but not changed?

Yes, but there's little point in doing so. If the file can be deleted, then it's straightforward for a user with the appropriate permissions to delete it and then create a new file with the same name. In fact, some programs, such as the Vim text editor, do this automatically while editing a file.

The most you will get is that the user doing the editing will be warned that the file is read-only and hopefully think twice before saving any changes.

Can I make an executable file so that someone else can run it in my name?

Yes. You can turn on the setuid and/or setgid bits. This must be done with care, as it involves security risks.

  • If the setuid bit is enabled on a file (chmod u+s file.exe), any operation done by file.exe when run by any user (provided that user has permission to execute file.exe at all) will be done as if by the owner of file.exe.
  • If the setgid bit is enabled on a file (chmod g+s file.exe), any operation done by file.exe when run by any user (provided that user has permission to execute file.exe at all) will be done as if by a member of file.exe's group.

Will files and directories created in a directory inherit its group?

Not by default. Normal behaviour is for a newly created file or directory to get the current default group of the creator. This behaviour can be changed by setting the parent directory's setgid bit. You can turn on a directory's setgid bit by using the following command:

chmod -R g+s directory

However, this flag only affects files and directories that are created within the directory. It does not affect the group of a file or directory that is created elsewhere and then moved into the directory. If you have created a file elsewhere (e.g., in your home directory) and are moving it into a project directory, we recommend that you check its owner and group to make sure they are appropriate.

What can I do if UNIX permissions aren't flexible enough for me?

You can use Access Control Lists.

Access Control Lists (ACLs)

Access Control Lists (abbreviated as ACLs) allow for fine-grained permission control For example, you have data that you only want to be visible to members of your project team, and you want some of your team members but not all to be able to edit the contents of the file. You can also grant permission to multiple groups.

Can I use ACLs to change the owner or group of a file or directory?

No. If you want to change the group, you have to use the chgrp command. If you want to change the owner, please contact support@nesi.org.nz.

Can I use ACLs to change the permissions on a file or directory?

Sometimes. You can use ACLs to grant particular permissions to specific users or groups that wouldn't otherwise have those permissions. But if the chmod command is used to withdraw certain permissions from everyone (for example, to make a file non-executable), any relevant privileges in that file's ACL will be overridden by the restriction imposed by chmod as long as the latter is in effect.

How can I tell whether a file has an ACL?

Run ls -l on the file. If the last character in the first field is a full stop (.), the file has no ACL other than what is implied by its UNIX permissions. If the last character is a plus sign (+), the file has an ACL.

How can I tell what a file or directory's ACL is?

Use the mmgetacl command.

/usr/lpp/mmfs/bin/mmgetacl /path/to/file

Please do not use the command getfacl as it reveals less information. In particular, mmgetacl, unlike getfacl, reveals who is allowed to edit the ACL itself.

How can I tell what a directory's default ACL is?

Use the mmgetacl command with the -d switch.

/usr/lpp/mmfs/bin/mmgetacl -d /path/to/directory

What's the difference between an ACL and a default ACL?

Directories have two types of ACL. The (plain) ACL is the ACL for the directory alone. The default ACL is the ACL that will be applied by default to files or directories created within that directory. The ACL and the default ACL for a directory will ordinarily be the same, and we recommend setting them this way. But this state of things is not enforced by our software, so you should take care to set your ACLs up appropriately.

How do I set or change an ACL on just one file or directory?

To set or change an ACL, we recommend using the following procedure:

Prepare a file containing the ACL you want to apply. The file should look like this:

# Lines starting with '#' are comments and will be ignored by mmputacl. They are
# included here for explanatory purposes only.
# Set permissions for the file's current owner and group, and for the world
user::rwxc
group::rwx-
other::----
# Set the mask. The mask is the highest permission that can be granted to any
# person or group except what is granted to the owner, group or world. Any
# permission granted to a non-owning user or group that is not granted to the
# mask will be silently suppressed. We highly recommend a mask of `rwxc` as it
# gives maximum flexibility whenever editing the ACL.
mask::rwxc
# Give permission to users other than the owner
user:jblo123:rwx-
user:jdoe456:r-x-
user:asmi789:rwxc
# Give permission to groups other than the file's group
group:admin:rwxc

Take note of the group of four characters at the end of each non-comment line. The first spot is read privileges: r for "may read", - for "may not read". The second is write privileges, with w and - having a corresponding meaning; the third, execute privileges, with x and -. The final spot, with a c or a - in it, grants the power to change the ACLs themselves. No-one can change the ACL who does not have a c either beside his or her name, or beside the name of a group of which he or she is a member.

Having crafted your ACL file, use the mmputacl command (or mmputacl -d to set a directory's default ACL).

# Set the ACL
/usr/lpp/mmfs/bin/mmputacl -i /path/to/aclfile.txt /path/to/file_or_directory
# Additionally set the default ACL (recommended for directories)
/usr/lpp/mmfs/bin/mmputacl -d -i /path/to/aclfile.txt /path/to/directory

How do I set or change an ACL recursively on a directory and its contents?

We have prepared a script for you to use when setting an ACL on a directory. You are welcome to run the following command on the Pan login node, having prepared an ACL file as described above:

fs_set_gpfs_acls_recursively -f /path/to/aclfile.txt /path/to/directory

Please note that, depending on the number of files and directories affected, this command may take a long time to run, and may affect running jobs if any permissions are withdrawn. If you have questions or concerns about either your proposed ACL or the effects of applying it to your intended directory, please contact our support team at support@nesi.org.nz.

What will happen to a file's ACL if I move or copy the file?

If you move the file (using the mv command), the command will attempt to preserve the ACL as much as possible, so only the parts of the ACL that aren't supported at the destination will be forgotten.

If you copy the file (using the cp command), the fate of the ACL will depend on the options you select:

  • If you use the -a, -p, --preserve=mode or --preserve=all flags, the command will preserve the existing ACL as far as possible.
  • If you do not use any of the above flags, the command will forget the existing ACL, and the new copy of the file will get an ACL based on the default ACL of the destination directory.

When you copy a file or directory into a project directory, or into any other directory that has a default ACL set, we recommend that you allow ACLs to be replaced. You can allow ACLs to be replaced at the destination in one of two ways, either of which requires you to use cp (followed, where needed, by rm) instead of mv:

  • As already mentioned, by avoiding the use of -a, -p, --preserve=mode and --preserve-all when copying.
  • If you would like to copy with -a (a fairly common scenario), or with any flag or flags that preserve attributes, you can explicitly refuse to preserve the ACLs.

The following form of the copy command can be used to explicitly replace ACLs while optionally preserving other attributes:

# Note that "--no-preserve=mode" must come after any flag that sets or alters
# the list of attributes to be preserved, otherwise it might be overridden.
# Preservation options specified later in the list of flags prevail over those
# specified earlier.
cp [ -flags ] --no-preserve=mode <arguments>

Comments

Powered by Zendesk