5 ms·

Sometimes I wish ACLs were better supported.

JdeBP 10y ago
POSIX ACLs, nee TRUSIX ACLs, are one of several ironies of the world of international standardization. Whilst the attempt to produce a formal standards document for them failed, they actually got implemented in many operating systems anyway with a fair degree of consistency. So whilst they are not de jure standardized, one can enjoy the de facto existence of tools like getfacl and setfacl across multiple operating systems today. That said, I agree that it would be most welcome if there were fewer niches where ACLs are still wholly unavailable: OpenBSD, tmpfs filesystems on FreeBSD, and so forth.
pinpelipon 10y ago
Combining both the ancestral and the ACL system was botched. Both are good on their own. The hybrid model is complex and hard to manage, even though it can technically fulfill most requirements you can think of. It's a real shame because it means ACL usage is not going to take off anywhere soon.
ndesaulniers 10y ago
Isn't that what SELinux is for when they say it's Mandatory Access Control? Or are those two different things?
- LukeShu 10y ago
  MAC and ACL are two different things. On Linux, ACL is the "facl" family of functions functions (and the set/getfacl programs). These supplement the traditional owner/group and mode bits. Essentially, it allows you to set a separate set of read/write/execute bits on a file for an arbitrary number of specific users or groups, rather than being limited to simply "owner", "group", "everyone-else". If anything is set beyond the normal owner/group/world, GNU `ls -l` indicates this with a "+" next to the normal mode bits. I'm unsure how much this changes for other kernels.
  - rleigh 10y ago
    Linux supports POSIX.1e DRAFT ACLs. These are a de-facto standard by implementation, but were never formally standardised by POSIX. They are also supported by other kernels. However, other systems support the more modern and featureful NFSv4 ACLs. NFSv4 ACLs are supported by the NFSv4 filesytem and also used by ZFS. They are part of the NFSv4 formal specification. On systems supporting ZFS (other than Linux), you get the full NFSv4 ACL support. Linux doesn't have VFS support for NFSv4 ACLs, and doesn't expose them even for NFSv4 mounts. In contrast, a FreeBSD mount of an NFSv4 filesystem served from ZFS exposes the full permissions model to the client. FreeBSD has a separate set of richer acl_* functions rather than the get/setfacl functions on Linux. Linux: % getfacl ~/.zshrc getfacl: Removing leading '/' from absolute path names # file: home/rleigh/.zshrc # owner: rleigh # group: rleigh user::rw- group::r-- other::r-- FreeBSD: % getfacl ~/.zshrc # file: /home/rleigh/.zshrc # owner: rleigh # group: rleigh owner@:rw-p--aARWcCos:-------:allow group@:r-----a-R-c--s:-------:allow everyone@:r-----a-R-c--s:-------:allow Linux really needs to get proper support for NFSv4 ACLs.
    - vetinari 10y ago
      > Linux really needs to get proper support for NFSv4 ACLs. Not to nitpick, but: why would it need to do that? Nobody (in Joel Spolsky definition of nobody) cares about NFSv4. The only place where ACL matters for Linux users is Samba. And Samba works fine with Linux ACLs as it is.
      - rleigh 10y ago
        Most people aren't aware of what they are missing and how it could bring a great deal of benefit. This isn't about NFSv4 (the filesystem), it's about the rich permissions model it standardised which is now used by more than just NFS. It's used by ZFS, and it's used by the FreeBSD and Solaris VFS, and likely others as well. It's the only rich ACL model in real use today on open platforms, and being a superset of both POSIX.1e DRAFT and Windows ACLs, it's needed for full interoperability between platforms. Samba doesn't "work fine" except for the simple case. Using it with groups and group permissions can be exceedingly painful. When I export a ZFS filesystem on FreeBSD over Samba, it exposes the full ACL model to the Windows client which is accessible and manipulable via the standard security properties as well as the command-line on the server or and NFSv4 clients. When working with group permissions locally or over NFSv4 or CIFS, you aren't restricted to the pitiful group and setgid permissions offered by the standard UNIX permissions or even POSIX.1e ACLs. You can add an @group ACE detailing the group access permissions and their inheritance, or custom ones per user, which can make working on shared data much simpler. No more pain when someone with a broken umask adds something and strips off the group permissions, or they drop the setgid bit and the inheritance is lost, or they access it via samba and it sets the wrong group ownership or permissions. All of which I see regularly on shares exported from Linux. We often have to export the same share multiple times with different configuration to work around the limitations (read-only, group and group perms), where if it was using proper ACLs just one would work for all cases.
- pjmlp 10y ago
  It is different, in any case SELinux as the name implies is Linux specific.
- cperciva 10y ago
  They're related, but not the same. ACLs are Access Control Lists; basically a more sophisticated version of UNIX permissions. Mandatory Access Control is about restricting what users can put into their ACLs; e.g., "Alice is not allowed to make any of her files readable by Bob".
- pinpelipon 10y ago
  Also, SELinux is not about just files. It controls some capabilities, and can be used to control the data inside applications as well.
jstimpfle 10y ago
Who has put ACLs to good use anyway? Even the old model usually forces one to overspecify one's intent. It's too easy to shoot in your foot, and too hard to figure out what you need in the first place. I doubt there is a good general purpose permission model that's more complex than Unix modes. Collaboration on filesystems just doesn't work very well. It could work for many small groups if files had no users associated and everybody had just R and W bits for a whole repository. For special problems there are specialized solutions. For example distributed models like git, or complex client-server solutions.
- JdeBP 10y ago
  Well, for starters there are every Windows NT system you have ever used, which uses ACLs quite successfully and extensively for a whole host of reasons, and ... me. I put ACLs to good use myself. Your wording, speaking of repositories and git, bespeaks a too-narrow idea of what ACLs can be used for. Aside from all of the examples that one can glean from Windows NT, from window stations to the trusted installer, there are things like using ACLs to govern access to in-filesystem control/status APIs, or using them to limit the things that a subverted logging daemon could possibly do.
  - jstimpfle 10y ago
    What's your own use case? Do you have a good source of example use cases for ACLs in Windows NT?
    - JoBrad 10y ago
      Our business uses them to restrict portions of our shared drive to certain groups. They're also used to restrict programmatic access to system folders, by Windows.
      - jstimpfle 10y ago
        And it's not possible to use conventional Unix groups for that?

JdeBP 10y ago

POSIX ACLs, nee TRUSIX ACLs, are one of several ironies of the world of international standardization. Whilst the attempt to produce a formal standards document for them failed, they actually got implemented in many operating systems anyway with a fair degree of consistency. So whilst they are not de jure standardized, one can enjoy the de facto existence of tools like getfacl and setfacl across multiple operating systems today. That said, I agree that it would be most welcome if there were fewer niches where ACLs are still wholly unavailable: OpenBSD, tmpfs filesystems on FreeBSD, and so forth.

pinpelipon 10y ago

Combining both the ancestral and the ACL system was botched. Both are good on their own. The hybrid model is complex and hard to manage, even though it can technically fulfill most requirements you can think of. It's a real shame because it means ACL usage is not going to take off anywhere soon.

ndesaulniers 10y ago

Isn't that what SELinux is for when they say it's Mandatory Access Control? Or are those two different things?

LukeShu 10y ago
MAC and ACL are two different things. On Linux, ACL is the "facl" family of functions functions (and the set/getfacl programs). These supplement the traditional owner/group and mode bits. Essentially, it allows you to set a separate set of read/write/execute bits on a file for an arbitrary number of specific users or groups, rather than being limited to simply "owner", "group", "everyone-else". If anything is set beyond the normal owner/group/world, GNU `ls -l` indicates this with a "+" next to the normal mode bits. I'm unsure how much this changes for other kernels.
- rleigh 10y ago
  Linux supports POSIX.1e DRAFT ACLs. These are a de-facto standard by implementation, but were never formally standardised by POSIX. They are also supported by other kernels. However, other systems support the more modern and featureful NFSv4 ACLs. NFSv4 ACLs are supported by the NFSv4 filesytem and also used by ZFS. They are part of the NFSv4 formal specification. On systems supporting ZFS (other than Linux), you get the full NFSv4 ACL support. Linux doesn't have VFS support for NFSv4 ACLs, and doesn't expose them even for NFSv4 mounts. In contrast, a FreeBSD mount of an NFSv4 filesystem served from ZFS exposes the full permissions model to the client. FreeBSD has a separate set of richer acl_* functions rather than the get/setfacl functions on Linux. Linux: % getfacl ~/.zshrc getfacl: Removing leading '/' from absolute path names # file: home/rleigh/.zshrc # owner: rleigh # group: rleigh user::rw- group::r-- other::r-- FreeBSD: % getfacl ~/.zshrc # file: /home/rleigh/.zshrc # owner: rleigh # group: rleigh owner@:rw-p--aARWcCos:-------:allow group@:r-----a-R-c--s:-------:allow everyone@:r-----a-R-c--s:-------:allow Linux really needs to get proper support for NFSv4 ACLs.
  - vetinari 10y ago
    > Linux really needs to get proper support for NFSv4 ACLs. Not to nitpick, but: why would it need to do that? Nobody (in Joel Spolsky definition of nobody) cares about NFSv4. The only place where ACL matters for Linux users is Samba. And Samba works fine with Linux ACLs as it is.
    - rleigh 10y ago
      Most people aren't aware of what they are missing and how it could bring a great deal of benefit. This isn't about NFSv4 (the filesystem), it's about the rich permissions model it standardised which is now used by more than just NFS. It's used by ZFS, and it's used by the FreeBSD and Solaris VFS, and likely others as well. It's the only rich ACL model in real use today on open platforms, and being a superset of both POSIX.1e DRAFT and Windows ACLs, it's needed for full interoperability between platforms. Samba doesn't "work fine" except for the simple case. Using it with groups and group permissions can be exceedingly painful. When I export a ZFS filesystem on FreeBSD over Samba, it exposes the full ACL model to the Windows client which is accessible and manipulable via the standard security properties as well as the command-line on the server or and NFSv4 clients. When working with group permissions locally or over NFSv4 or CIFS, you aren't restricted to the pitiful group and setgid permissions offered by the standard UNIX permissions or even POSIX.1e ACLs. You can add an @group ACE detailing the group access permissions and their inheritance, or custom ones per user, which can make working on shared data much simpler. No more pain when someone with a broken umask adds something and strips off the group permissions, or they drop the setgid bit and the inheritance is lost, or they access it via samba and it sets the wrong group ownership or permissions. All of which I see regularly on shares exported from Linux. We often have to export the same share multiple times with different configuration to work around the limitations (read-only, group and group perms), where if it was using proper ACLs just one would work for all cases.
pjmlp 10y ago
It is different, in any case SELinux as the name implies is Linux specific.
cperciva 10y ago
They're related, but not the same. ACLs are Access Control Lists; basically a more sophisticated version of UNIX permissions. Mandatory Access Control is about restricting what users can put into their ACLs; e.g., "Alice is not allowed to make any of her files readable by Bob".
pinpelipon 10y ago
Also, SELinux is not about just files. It controls some capabilities, and can be used to control the data inside applications as well.

jstimpfle 10y ago

Who has put ACLs to good use anyway? Even the old model usually forces one to overspecify one's intent. It's too easy to shoot in your foot, and too hard to figure out what you need in the first place. I doubt there is a good general purpose permission model that's more complex than Unix modes. Collaboration on filesystems just doesn't work very well. It could work for many small groups if files had no users associated and everybody had just R and W bits for a whole repository. For special problems there are specialized solutions. For example distributed models like git, or complex client-server solutions.

JdeBP 10y ago
Well, for starters there are every Windows NT system you have ever used, which uses ACLs quite successfully and extensively for a whole host of reasons, and ... me. I put ACLs to good use myself. Your wording, speaking of repositories and git, bespeaks a too-narrow idea of what ACLs can be used for. Aside from all of the examples that one can glean from Windows NT, from window stations to the trusted installer, there are things like using ACLs to govern access to in-filesystem control/status APIs, or using them to limit the things that a subverted logging daemon could possibly do.
- jstimpfle 10y ago
  What's your own use case? Do you have a good source of example use cases for ACLs in Windows NT?
  - JoBrad 10y ago
    Our business uses them to restrict portions of our shared drive to certain groups. They're also used to restrict programmatic access to system folders, by Windows.
    - jstimpfle 10y ago
      And it's not possible to use conventional Unix groups for that?