• Yerbouti@lemmy.ml
    link
    fedilink
    arrow-up
    47
    arrow-down
    1
    ·
    9 months ago

    I have no idea what is going on but this looks good. I agree with you guys. Upvoted.

    • tal@lemmy.today
      link
      fedilink
      arrow-up
      31
      ·
      9 months ago

      Yeah, but I think all reasonably-modern Unixy filesystems on Linux will support ACLs. ext2/3/4, btrfs, xfs, zfs, jfs, etc.

    • 520@kbin.social
      link
      fedilink
      arrow-up
      12
      ·
      9 months ago

      Yes. Some filesystems straight up do not support ACL of any kind (eg: fat32)

      • velovix@hedge.town
        link
        fedilink
        arrow-up
        10
        ·
        9 months ago

        Fat32 doesn’t support regular file permissions either, right? I was under the impression that it was permissionless.

        • zero_iq@lemm.ee
          link
          fedilink
          arrow-up
          27
          ·
          edit-2
          9 months ago

          Sorry, but this is completely wrong.

          Windows has ACLs and they are an important part of Windows administration, and used extensively for managing file permissions.

          Windows has supported ACLs on NTFS since Windows NT & NTFS were released in 1993 (possibly partly influenced by AIX ACLs in the late 80s influenced by VMS ACLs introduced the early 80s).

          ACLs were not introduced to standard POSIX until c.1998, and NFS and Linux filesystems didn’t get them until 2003. In fact, the design of the NFSv4 ACL standard was heavily influenced by the design of NTFS/Windows ACL model – a specific decision by the designers to model it more like NTFS rather than AIX/POSIX.

          Technically, at the filesystem level, exFAT also provides support for ACLs, but I am not sure if any implementation actually makes use of this feature (not even Windows AFAIK, certainly not any desktop version).

          • davefischer@beehaw.org
            link
            fedilink
            English
            arrow-up
            6
            ·
            9 months ago

            Windows NT ACLs come from VMS.

            The Unix world has traditionally not liked ACLs because Multics had them, and Unix was an ultra-minimalist response to Multics.

            • zero_iq@lemm.ee
              link
              fedilink
              arrow-up
              4
              ·
              edit-2
              9 months ago

              Yep, you’re right. I was thinking of an ACL evolution/chain of influence of VMS -> AIX -> NT, but it seems VMS -> NT and VMS -> AIX as two separate histories is much more accurate. Thanks for the correction – I’ve updated my comment accordingly.

                • zero_iq@lemm.ee
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  9 months ago

                  VMS implemented ACLs in the early 80s. It’s design influenced the design of ACLs in both AIX and Windows NT.

          • panicnow@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            9 months ago

            Damn, giving me flashbacks of slowly moving through ACLs then hitting domain groups, domain local groups, global groups, then eventually universal groups as AD moved forward in complex situations.

            Got to admit it worked well though.

        • 520@kbin.social
          link
          fedilink
          arrow-up
          23
          ·
          edit-2
          9 months ago

          Bruh, Windows has had ACLs for decades. Before Linux, even. What are you smoking?

          I wouldn’t be surprised if the NTFS driver for Linux doesn’t support ACLs though.

  • palordrolap@kbin.social
    link
    fedilink
    arrow-up
    26
    ·
    9 months ago

    Technically, this is also possible by creating extra groups, but this kind of access control presumably exists because the old-school method can be a pain to administer. Choosing group names can also be an “interesting” secondary challenge.

    i.e. Dude’s not going to be best pleased if they ls -l and see the group on the file is xyzgroup-but-not-dude even if it is with good reason. (Shouldn’t have deleted the database, dude.)

    • tal@lemmy.today
      link
      fedilink
      arrow-up
      15
      ·
      9 months ago

      I don’t really think that that’s a realistic goal for ACLs. I mean, getfacl showing the user specifically being excluded probably isn’t any more-polite.

    • Papamousse@beehaw.org
      link
      fedilink
      arrow-up
      13
      ·
      9 months ago

      In a previous life (in the 90s) I was a un*x sysadmin, and ACL is nightmarish in big company, I hated it and avoided it

  • Deconceptualist@lemm.ee
    link
    fedilink
    English
    arrow-up
    19
    arrow-down
    1
    ·
    edit-2
    9 months ago

    Cool, I didn’t know ACLs were a widely available thing but the infographic explains pretty well! Sounds really useful when granular controls are needed, but I could also imagine it being a huge pain in environments already built out and scripted around regular permissions. Still as always, options are good and an ounce of planning is worth a pound of troubleshooting.

    I do low-key hate seeing a directory named “dir” and a group named “me” though. That’s chaotic neutral shit at the very least.

  • doktorseven@lemmy.world
    link
    fedilink
    arrow-up
    18
    arrow-down
    1
    ·
    9 months ago

    Confusing. You set a mask for a user and somehow it propagated down to a group and then you change permission on that group suddenly it applies to the user? Either something is wrong here or ACL permissions make absolutely zero sense. It is 5 billion times easier to use normal permissions to set these things up.

    • Deiskos@lemmy.world
      link
      fedilink
      arrow-up
      13
      arrow-down
      1
      ·
      edit-2
      9 months ago

      I think it’s like this: what used to be group in regular permissions output is a union of group and ACL mask in ACL output. Mask sets the upper limit of what ACL can do, so if mask is rw- then it’s impossible to set a r-x ACL permission because allowing execution is not allowed.

      This seems to be more geared towards enterprise environment where it could be complicated to cleanly define groups, since you can only give access to one you might run into a problem where dept. A needs access to that directory but also person G from dept. B and person K from dept. C.

    • Zangoose@lemmy.world
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      2
      ·
      9 months ago

      Permissions are listed as “user”, “group”, “other”. I.e. the user who made the file, the group of the user who made the file (usually just their name as a group), and everyone else. In this case the rxw is for the user.

      For chmod, you can also represent these as binary numbers: 111 would mean having all 3, 101 would mean having read and write, etc. These binary numbers then get turned back into regular numbers (7 in the first example, since it’s 111) for chmod. Giving a file “chmod 777” means the user, group, and other all have full permissions on the file. “chmod 700” gives the creator full control, but no one else can view, modify, or execute the file.

        • Zangoose@lemmy.world
          link
          fedilink
          English
          arrow-up
          5
          ·
          9 months ago

          Oh I completely missed that lol. Oh well, it’s probably still a useful explanation for someone else reading this

        • Zangoose@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          9 months ago

          🤷‍♂️ They’re just internet points, lemmy doesn’t notify about up/downvotes so I will only see it if people respond. Either way it’s hopefully still useful to someone else looking at the post who isn’t familiar with basic permissions or acl

  • PowerCrazy@lemmy.ml
    link
    fedilink
    arrow-up
    12
    arrow-down
    9
    ·
    9 months ago

    The only thing you need to know about file acls is not to use them. Similar thing can be said for Network ACLs to be honest.

    • R0cket_M00se@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      9 months ago

      I’ve been a network engineer for five years at three companies and not a one has used switch or router based ACL’s. It’s all in the FW appliance.

      • PowerCrazy@lemmy.ml
        link
        fedilink
        arrow-up
        6
        arrow-down
        7
        ·
        9 months ago

        Network ACLs are my bane. Someone long ago decided we needed to “isolate” the network, so they put ACLs everywhere and so now 50% of my teams time is spend fucking with ACLs :/ It’s awful.

        • R0cket_M00se@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          9 months ago

          Yeah don’t get me wrong it’s an excellent part of network security but if it’s not defined primarily on one device it’s a hassle.

          • PowerCrazy@lemmy.ml
            link
            fedilink
            arrow-up
            1
            arrow-down
            7
            ·
            9 months ago

            Only if you assume IP Addresses act as authentication for what that host is. But since they don’t, I see ACLs as a security blanket.
            I can change the IP of a server I control and bypass any ACL easily. If I have control of my network as well, then no ACL you apply can stop any of my servers from hitting whatever server you have allowed any of my servers to hit. So why not just allow my entire network block?

            • R0cket_M00se@lemmy.world
              link
              fedilink
              English
              arrow-up
              4
              arrow-down
              1
              ·
              9 months ago

              I don’t assume that, and that’s why I only consider IP based ACL’s as a “part of this balanced security solution” because while handy, modern attacks are smarter everyday and heuristics based NIP systems are essential.

              In the military we called it the “swiss cheese model”, in ORM you use as many layers of security as you can to prevent a mishap. Controlling what subnets can access certain others keeps Becky from accounts payable from getting access into accounts receivable’s data and writing her own checks. Sure, a network admin/sysadmin could just change their IP, but Becky doesn’t have that access. I usually define network access by the subnet, if we aren’t comfortable with all devices in a LAN having access then it’s a pretty locked down solution, in which case we most likely have higher level requirements like application/port number or port security .1X.

              I’m assuming your servers all reside in the same subnet? If not, changing the IP without changing the VLAN and/or trunking it to the access layer switch you’re attached to would only result in a loss of connection.

              For your use case I’d just allow the whole LAN and define applications we are ok with having communications between the two subnets, and as always a well thought out DMZ goes a really long way.

              • PowerCrazy@lemmy.ml
                link
                fedilink
                arrow-up
                5
                arrow-down
                7
                ·
                9 months ago

                Right but if you want to start doing application level blocking, then the proper tool for the job is a stateful firewall and even better, a RADIUS/Kerberos system that authenticates every connection between servers.

                Basically I use ACLs to prevent spoofing attacks from originating out of my network, and also to lock down the management plane of my network devices to specific subnets. In all other cases a stateful firewall should be used exclusively.

                In any other case ACLs provide the illusion of security and create a huge amount of operational friction especially in a dynamic environment.