&quot;The old (other, group, user) * (read, write, execute) unix model is [...] sufficient for the vast majority of uses.&quot;<p>It&#x27;s really not, in an even moderately-complex environment. What I&#x27;ve seen most often is that the &quot;user&quot; and &quot;group&quot; permissions get eaten up by other factors (e.g. the &quot;user&quot; is a service account), so the only permission that can meaningfully be altered is &quot;other&quot;.<p>The result is that either all of the people who support whatever the app is doing have to be given sudo permissions as the service account (drastically reducing the value of any audit&#x2F;logging), or access has to be controlled at the OS level in terms of who can log onto the system in the first place. In other words, band-aids to work around the limitations of the traditional Unix filesystem permission model.