Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a different enough system, I think it's worth restating what Linux's present ACLs are, which were based on a POSIX draft: They are additive permissions that model the Unix mode bits. Per-user and per-group, you can add read, write, and execute permissions that they otherwise would not have.

NFSv4 ACLs are far more powerful, modeled after NTFS ACLs (a proper superset, with an added two permission types). In network environments (where you'd use them anyway), they can assign access control entries (ACE) with Security IDs (SIDs), generally more stable and consistent across a network than ad-hoc Unix user IDs/group IDs. Managing with UIDs/GIDs is still possible, too. They add both allow and deny permissions to ACLs; if you want to deny "fred" from reading a file, you can make a deny entry for "fred" specifically.

The fine-grained permissions you can get from NFSv4 ACLs: READ_DATA, LIST_DIRECTORY, WRITE_DATA, ADD_FILE, APPEND_DATA, ADD_SUBDIRECTORY, READ_NAMED_ATTRS, WRITE_NAMED_ATTRS, EXECUTE, DELETE_CHILD, READ_ATTRIBUTES, WRITE_ATTRIBUTES, DELETE, READ_ACL, WRITE_ACL, WRITE_OWNER, SYNCHRONIZE.

READ_DATA, WRITE_DATA, EXECUTE are equivalent to the read/write/execute Unix mode bits. The two expanded features I find I use most frequently are blocking the deletion of files and making them append-only.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: