The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Grant Taylor <gtaylor@tnetconsulting.net>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Who's behind the UNIX filesystem permission implementation
Date: Wed, 31 Jul 2019 15:01:30 -0400	[thread overview]
Message-ID: <CAC20D2PCQDrMWPAA8pRsFOEpH_L_yCE9Kd=4q7pFTBh+eN84+g@mail.gmail.com> (raw)
In-Reply-To: <b08a5508-0fc7-3a02-772c-405717c152f1@spamtrap.tnetconsulting.net>

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

On Wed, Jul 31, 2019 at 2:46 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> I thought that ACLs acted as additional gates / restriction points
> beyond what standard Unix file system permissions allowed.
>
It's really how strict you want to be in the definition of an ACL.   UNIX
uses the same basic/simple model but traditional UNIX style ACLs of 3
options of 3 modes are implemented are just more coarsely defined than say
VMS or later NT or SELinux, uses for their file systems.   It's arguable
that the extra granularity of the others actually adds a great deal in
actual day to day use cases.

At one time, I will admit that I had thought VMS style ACLs might be more
helpful to UNIX and we added them to one of our file systems, but when I
look back on 40 years of using anything beyond UNIX style ACLs its been
pretty rare when I actually needed much more (*i.e.* theory vs. practice).

The problem is the programming interface tends to get more difficult when
you add some of the extra features.   To me the brilliance to UNIX has
always been getting down to a very simple interface that was "good enough"
to get the *job done* and not so full of *extra stuff *that it gets in the
way (which tends to be a complaint by way with Linux -- which does have a
lot of new/rich features, but so full of some many different features
theses days you have to wonder is/was it worth it).

To me, it's arguable that ACL's beyond R/W/E and U/G/E is really needed in
practice.

Clem

[-- Attachment #2: Type: text/html, Size: 2801 bytes --]

  reply	other threads:[~2019-07-31 19:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31  9:59 Stephan Han.
2019-07-31 16:49 ` Rodrigo G. López
2019-07-31 17:29   ` Arthur Krewat
2019-07-31 17:58     ` Clem Cole
2019-07-31 18:03     ` Christopher Browne
2019-07-31 20:16     ` Arthur Krewat
2019-07-31 17:00 ` Toby Thain
2019-07-31 17:18   ` Warner Losh
2019-07-31 22:24     ` William Corcoran
2019-07-31 22:49       ` George Michaelson
2019-07-31 18:46   ` Grant Taylor via TUHS
2019-07-31 19:01     ` Clem Cole [this message]
2019-07-31 19:34     ` Ben Greenfield via TUHS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2PCQDrMWPAA8pRsFOEpH_L_yCE9Kd=4q7pFTBh+eN84+g@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=gtaylor@tnetconsulting.net \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).