ACL Explained; A Use Case for Data Protection
The advantage of the Access Control List (ACL) over standard Linux file permissions to comply with data protection regulations
Compliance with data protection regulations is becoming increasingly important nowadays. In my daily work as a Data Scientist, I‘m experiencing the challenge of how paperwork actually needs to be implemented down to the level of file access control to fulfill regulations such as GDPR.
ACL in Linux is a fine-graded permission control mechanism to access file system entities. It extends the concept of standard file permissions and allows more detailed management of who can do what on different object levels.
Some great data science tools like Dataiku Data Science Studio, with support for multi-user security (a.k.a. user isolation or user impersonation), utilize ACL to implement fine-graded data access permissions. Which is a great feature to comply with the latest data protection requirements in the field of data science.
Standard file permissions
The traditional Linux/Unix file permission control mechanism allows file access customization on the granularity level of owners, groups, and others. As the example below shows, upon file creation — and depending on some system settings — only the owner, ubuntu, and its group (also ubuntu in this case) have read/write access to the content of the file lorem.txt. Everyone else — except root, of course — can only read the content but cannot update it.
ubuntu@host:~$ echo "ipsum" > lorem.txtubuntu@host:~$ ls -l
-rw-rw-r-- 1 ubuntu ubuntu 6 Nov 29 16:39 lorem.txt
The above file permissions -rw-rw-r-- translates from left to right to
- read/write access for the owner ubuntu
- read/write access for the group ubuntu
- read-only access for all others
Everyone can read that file, which may not be our desire from the data protection point of view. The question arises now: How to allow access to the file content for an arbitrary user with appropriate clearance only (e.g., for John Doe)?
To start with standard file access permissions, one needs to forbid access for all others.
ubuntu@host:~$ chmod 740 lorem.txt
ubuntu@host:~$ ls -l
-rwxr----- 1 ubuntu ubuntu 6 Nov 29 16:39 lorem.txtjohn_doe@host:~$ cat /home/ubuntu/lorem.txt
cat: /home/ubuntu/lorem.txt: Permission denied
As we can see now, as long as John Doe is not a member of the group ubuntu and tries to read that file, he gets permission denied. To bring this further with standard file access permissions and grant access for John, one needed to add him to the group ubuntu and give that group write permissions.
Obviously, we just moved from dedicated user access management to group access management, which is considered a good system admin practice but not necessarily the best choice for data protection compliance and auditability
ACL in action — explained simply
ACL offers a much better solution with just a view prerequisites to fulfill, as follows:
- A file system with ACL support (like Ext4 or XFS) mounted with the acl option activated.
- The package acl installed (it’s easy, on ubuntu 18.04:
apt-get install acl).
The ACL settings can be listed by the command getfacl . If no ACL were set explicitly, getfacl shows the standard file permissions with much better readability than the standard ls -l command.
ubuntu@host:~$ getfacl lorem.txt
# file: lorem.txt
# owner: ubuntu
# group: ubuntu
user::rwx
group::r--
other::---We are now very close to achieving our goal and allowing John read/write access to the file content by tailoring the ACL settings individually for him using setfacl. The command below translates as follows: Modify the ACL settings for user john_doe with r/w access for the specified text file.
ubuntu@host:~$ setfacl -m u:john_doe:rw lorem.txtAfter the above ACL update John Doe, although still not a member of the group ubuntu, is now able to read or update the file lorem.txt while others are still not allowed, as the output of getfacl clearly shows below.
ubuntu@host:~$ getfacl lorem.txt
# file: lorem.txt
# owner: ubuntu
# group: ubuntu
user::rwx
user:john_doe:rw-
group::r--
mask::rw-
other::---john_doe@host:~$ cat /home/ubuntu/lorem.txt
ipsumjohn_doe@host:~$ echo "dolor" >> /home/ubuntu/lorem.txt
john_doe@host:~$ cat /home/ubuntu/lorem.txt
ipsum
dolor
Now, if we look at the standard file permissions with ls -l like at the beginning, notice the plus sign at the end of the file permissions block.
ubuntu@host:~$ ls -l
-rw-rw-r--+ 1 ubuntu ubuntu 6 Nov 29 16:40 lorem.txtThat indicates active ACL settings and warns to interpret file permissions differently than without ACL. The mask rw is now printed at the place where normally standard group permissions are shown. This is not to confuse with those permissions, which still allow read-only access for the members of the group ubuntu.
The tool setfacl is quite powerful with many options, as explained in full here.
Conclusion
This article’s main takeaway is that creating a volume mount with ACL support when a Kubernetes pod runs inside Docker Desktop on a Mac could be challenging but possible.
My post “Persistent Volume for Kubernetes w/ ACL Support on Mac” describes a practical use case for ACL.
