On the surface, they are as simple as Linux UOG/rwx stuff if you want it to be, but you can really, REALLY dive into the technology and apply super specific permissions.
You have a hardened Windows 11 system. A critical application was brought forward from a Windows 10 box but it failed, probably a permissions issue somewhere. Debug it and get it working. You can not try to pass this off to the vendor, it is on you to fix it. Go.
And then you get security product who have the fun idea of removing privileges when a program creates a handle (I'm not joking, that's a thing some products do). So when you open a file with write access, and then try to write to the file, you end up with permission errors durig the write (and not the open) and end up debugging for hours on end only to discover that some shitty security product is doing stupid stuff...
Granted, thats not related to ACLs. But for every OK idea microsoft had, they have dozen of terrible ideas that make the whole system horrible.
This makes writing robust code under those systems a lot easier, which in turns makes debugging things when it goes wrong nicer. Now, I'm not going to say debugging those systems is great - SELinux errors are still an inscrutable mess and writing SELinux policy is fairly painful.
But there is real value in limiting where errors can crop up, and how they can happen.
Of course, there is stuff like FUSE that can throw a wrench into this: instead of an LSM, a linux security product could write their own FS overlay to do these kind of shenanigans. But those seem to be extremely rare on Linux, whereas they're very commonplace on Windows - mostly because MS doesn't provide the necessary tools to properly write security modules, so everyone's just winging it.
Also, as far as I know Linux doesn't support DENY ACLs, which Windows does.
Wouldn't the o::--- default ACL, like mode o-rwx, deny others access in the way you're describing?
Here is kernel dev telling they are against adding NFSv4 ACL implementation. The relevant RichAcls patch never got merged: https://lkml.org/lkml/2016/3/15/52
I see what I misunderstood, even in the presence of an ALLOW entry, a DENY entry would prohibit access. I am familiar with that on the Windows side but haven't really dug into Linux ACLs. The ACCESS CHECK ALGORITHM[1] section of the acl(5) man page was pretty clear, I think.
[1] https://man7.org/linux/man-pages/man5/acl.5.html#ACCESS_CHEC...
Ubuntu just recently got a way to automate its installer (recently being during covid). I think you can do the same on RHEL too. But that's largely it on Linux right now. If you need to admin 10,000+ computers, Windows is still the king.
1. cloud-init support was in RHEL 7.2 which released November 19, 2015. A decade ago.
2. Checking on Ubuntu, it looks like it was supported in Ubuntu 18.04 LTS in April 2018.
3. For admining tens of thousands of servers, if you're in the RHEL ecosystem you use Satellite and it's ansible integration. That's also been going on for... about a decade. You don't need much integration though other than a host list of names and IPs.
There are a lot of people on this list handling tens of thousands or hundreds of thousands of linux servers a day (probably a few in the millions).
Preseed is not new at all:
https://wiki.debian.org/DebianInstaller/Preseed
RH has also had kickstart since basically forever now.
I've been using both preseeds and kickstart professionally for over a decade. Maybe you're thinking of the graphical installer?
What?! I was doing kickstart on Red Hat (want called Enterprise Linux back then) at my job 25 years ago, I believe we were using floppies for that.
BTW, we managed to get the earlies history of the project written down here by one of the earliest contributors for anyone who might be interested:
https://anaconda-installer.readthedocs.io/en/latest/intro.ht...
As for how the automated installation on RHEL, Fedora and related distros works - it is indeed via kickstart:
https://pykickstart.readthedocs.io/en/latest/
Note how some commands were introduced way back in the single digit Fedora/Fedora Core age - that was from about 2003 to 2008. Latest Fedora is Fedora 43. :)
- There does not seem to be a way to determine which machines in the fleet have successfully applied. If you need a policy to be active before doing deployment of something (via a different method), or things break, what do you do?
- I’ve had far too many major incidents that were the result of unexpected interactions between group policy and production deployments.