Skip to main content

Access Control Lists

Permission bits name three parties: the owner, the owning group, and everyone else. An access control list names as many users and groups as the object needs.

What it is​

Access Control Lists (ACLs) grant permissions to named users and named groups, beyond the owner, the owning group, and everyone else. An object can have an access ACL, which decides who may do what to the object. A directory can have a second, default ACL, which supplies the permissions that objects created inside the directory start with.

These are the POSIX ACLs, not a MooseFS invention. On Linux, the system's own getfacl and setfacl read and write ACLs on a mount. MooseFS ships mfsgetfacl and mfssetfacl for the same job.

Why it matters​

On a cluster, the Master Server evaluates ACLs. Two clients on two machines therefore get one answer to the same permission question. No mount can decide otherwise on its own. The mount asks the Master Server, and the Master Server answers.

How MooseFS implements it​

ACLs are part of the metadata that the Master Server holds, kept per object and separately from the object's other attributes. They go into the metadata image and the changelog, so they remain after a restart of the Master Server.

Permission checks run in the Master Server. When an object has an access ACL, the Master Server evaluates that ACL instead of the mode bits. A new object starts from the default ACL of the directory where the object is created, if that directory has one. Taking a snapshot of an object copies its ACLs along with the object.

The generic extended attribute calls also give access to the same lists. A mount translates the names system.posix_acl_access and system.posix_acl_default into ACL operations. A program that works through getxattr and setxattr therefore reads and writes an object's ACLs without knowing anything about MooseFS. listxattr reports both names on an object that has an ACL. Neither name is stored as an extended attribute. The mount answers a request for either name from the ACL itself.

An export rule can forbid the clients it admits to set ACLs (see Session and export). For a short time, a mount caches the attributes that it has read. An ACL changed through one mount is therefore not always visible at once through a second mount.

  • Access control: the export entry that admits a mount, and the operations that the entry can forbid that mount, setfacl among them.
  • Windows Client permissions: how ACLs are mapped in both directions for a Windows Client.