The Unix Heritage Society mailing list
 help / color / Atom feed
* Re: [TUHS] Who's behind the UNIX filesystem permission
@ 2019-08-01 23:43 jnc
  2019-08-02  1:03 ` David Arnold
  2019-08-07  2:35 ` Dave Horsfall
  0 siblings, 2 replies; 16+ messages in thread
From: jnc @ 2019-08-01 23:43 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Dave Horsfall

    > it actually *unlinked* directories

Maybe the application was written by a LISP programmer? :-)

(Not really, of course; it was probably just someone who didn't know much
about Unix. They had a list of system calls, and 'unlink' probably said ' only
works on directories when the caller is root', so...)

Speaking of LISP and GC, it's impressive how GC is not really a big issue any
more. At one point people were even building special CPUs that had hardware
support for GC; now it seems to be a 'solved problem' on ordinary CPUs.

	Noel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 23:43 [TUHS] Who's behind the UNIX filesystem permission jnc
@ 2019-08-02  1:03 ` David Arnold
  2019-08-02  4:36   ` Rob Pike
  2019-08-07  2:35 ` Dave Horsfall
  1 sibling, 1 reply; 16+ messages in thread
From: David Arnold @ 2019-08-02  1:03 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

On 2 Aug 2019, at 09:43, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

> Speaking of LISP and GC, it's impressive how GC is not really a big issue any
> more. At one point people were even building special CPUs that had hardware
> support for GC; now it seems to be a 'solved problem' on ordinary CPUs.

I think it’s mostly a side effect of modern hardware speeds. For applications that care about latency (and especially latency jitter) it’s still an issue. 

For example, writing low latency trading software in Java requires some fairly silly hoop-jumping to avoid triggering a collection pass.

These apps genuinely care about nanoseconds, but the tooling ecosystem and development time advantages of Java seem to entice a decent number of people to embark on the work-arounds. 

In most areas though you’re absolutely right — it’s a non-issue now. 



d

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-02  1:03 ` David Arnold
@ 2019-08-02  4:36   ` Rob Pike
  0 siblings, 0 replies; 16+ messages in thread
From: Rob Pike @ 2019-08-02  4:36 UTC (permalink / raw)
  To: David Arnold; +Cc: The Eunuchs Hysterical Society, Noel Chiappa

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

In Go we "just" dedicate a core to GC, problem solved. The arrival of
universal multi-CPU hardware made than option. Some tremendous technical
work required (for which I take zero credit; see
https://blog.golang.org/ismmkeynote) but yeah.

-rob


On Fri, Aug 2, 2019 at 11:11 AM David Arnold <davida@pobox.com> wrote:

> On 2 Aug 2019, at 09:43, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>
> > Speaking of LISP and GC, it's impressive how GC is not really a big
> issue any
> > more. At one point people were even building special CPUs that had
> hardware
> > support for GC; now it seems to be a 'solved problem' on ordinary CPUs.
>
> I think it’s mostly a side effect of modern hardware speeds. For
> applications that care about latency (and especially latency jitter) it’s
> still an issue.
>
> For example, writing low latency trading software in Java requires some
> fairly silly hoop-jumping to avoid triggering a collection pass.
>
> These apps genuinely care about nanoseconds, but the tooling ecosystem and
> development time advantages of Java seem to entice a decent number of
> people to embark on the work-arounds.
>
> In most areas though you’re absolutely right — it’s a non-issue now.
>
>
>
> d
>

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

<div dir="ltr">In Go we &quot;just&quot; dedicate a core to GC, problem solved. The arrival of universal multi-CPU hardware made than option. Some tremendous technical work required (for which I take zero credit; see <a href="https://blog.golang.org/ismmkeynote">https://blog.golang.org/ismmkeynote</a>) but yeah.<div><br></div><div>-rob</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 2, 2019 at 11:11 AM David Arnold &lt;<a href="mailto:davida@pobox.com">davida@pobox.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2 Aug 2019, at 09:43, Noel Chiappa &lt;<a href="mailto:jnc@mercury.lcs.mit.edu" target="_blank">jnc@mercury.lcs.mit.edu</a>&gt; wrote:<br>
<br>
&gt; Speaking of LISP and GC, it&#39;s impressive how GC is not really a big issue any<br>
&gt; more. At one point people were even building special CPUs that had hardware<br>
&gt; support for GC; now it seems to be a &#39;solved problem&#39; on ordinary CPUs.<br>
<br>
I think it’s mostly a side effect of modern hardware speeds. For applications that care about latency (and especially latency jitter) it’s still an issue. <br>
<br>
For example, writing low latency trading software in Java requires some fairly silly hoop-jumping to avoid triggering a collection pass.<br>
<br>
These apps genuinely care about nanoseconds, but the tooling ecosystem and development time advantages of Java seem to entice a decent number of people to embark on the work-arounds. <br>
<br>
In most areas though you’re absolutely right — it’s a non-issue now. <br>
<br>
<br>
<br>
d<br>
</blockquote></div>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 23:43 [TUHS] Who's behind the UNIX filesystem permission jnc
  2019-08-02  1:03 ` David Arnold
@ 2019-08-07  2:35 ` Dave Horsfall
  1 sibling, 0 replies; 16+ messages in thread
From: Dave Horsfall @ 2019-08-07  2:35 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Thu, 1 Aug 2019, Noel Chiappa wrote:

> Maybe the application was written by a LISP programmer? :-)
>
> (Not really, of course; it was probably just someone who didn't know much
> about Unix. They had a list of system calls, and 'unlink' probably said ' only
> works on directories when the caller is root', so...)

I dimly recall that there was a little-documented utility /etc/unlink 
which did just that; it was probably not on all systems, but was on our 
CCI Power 6/32.

I only discovered their incompetence at the next reboot, when I had to 
clean up all the orphaned (but temporary) files that were left behind 
because [idn]check went berserk (we didn't have fsck back then).

-- Dave

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-02 21:23   ` Dave Horsfall
@ 2019-08-03 12:51     ` Nemo
  0 siblings, 0 replies; 16+ messages in thread
From: Nemo @ 2019-08-03 12:51 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

On 02/08/2019, Dave Horsfall <dave@horsfall.org> wrote:
> That's why I use the symbolic modes on "chmod" instead of the octal ones

+1

> :-)
>
> -- Dave
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-02 15:17 ` Arthur Krewat
@ 2019-08-02 21:23   ` Dave Horsfall
  2019-08-03 12:51     ` Nemo
  0 siblings, 1 reply; 16+ messages in thread
From: Dave Horsfall @ 2019-08-02 21:23 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Fri, 2 Aug 2019, Arthur Krewat wrote:

> Sticky bit is the low-order bit on the first octet which is usually left 
> off and assumed to be zero. So to set it, it would be 1755. 4755 would 
> be setuid.

That's why I use the symbolic modes on "chmod" instead of the octal ones :-)

-- Dave

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-02 14:35 jnc
  2019-08-02 15:01 ` Clem Cole
@ 2019-08-02 15:17 ` Arthur Krewat
  2019-08-02 21:23   ` Dave Horsfall
  1 sibling, 1 reply; 16+ messages in thread
From: Arthur Krewat @ 2019-08-02 15:17 UTC (permalink / raw)
  To: tuhs



On 8/2/2019 10:35 AM, Noel Chiappa wrote:
>      > From: Arthur Krewat
>
>      > there's the setuid bit on directories - otherwise known as the sticky
>      > bit.
>
> Minor nit; in V6 at least (not sure about later), the 'sticky' bit was a
> separate bit from SUID and SGID. (When set on a pure/split object file, it
> told the OS to retain the text image on the swap device even when no active
> process was using it. Hence the name...)
>

Ah yes, I remember that now... sorry.

Sticky bit is the low-order bit on the first octet which is usually left 
off and assumed to be zero. So to set it, it would be 1755. 4755 would 
be setuid. Woops.

art k.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-02 14:35 jnc
@ 2019-08-02 15:01 ` Clem Cole
  2019-08-02 15:17 ` Arthur Krewat
  1 sibling, 0 replies; 16+ messages in thread
From: Clem Cole @ 2019-08-02 15:01 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS main list

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

On Fri, Aug 2, 2019 at 10:58 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     Minor nit; in V6 at least (not sure about later), the 'sticky' bit was
> a
> separate bit from SUID and SGID. (When set on a pure/split object file, it
> told the OS to retain the text image on the swap device even when no active
> process was using it. Hence the name...)
>
Indeed, nice catch, Noel.

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

<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 2, 2019 at 10:58 AM Noel Chiappa &lt;<a href="mailto:jnc@mercury.lcs.mit.edu">jnc@mercury.lcs.mit.edu</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">    Minor nit; in V6 at least (not sure about later), the &#39;sticky&#39; bit was a<br>
separate bit from SUID and SGID. (When set on a pure/split object file, it<br>
told the OS to retain the text image on the swap device even when no active<br>
process was using it. Hence the name...)<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Indeed, nice catch</span><span class="gmail_default" style="">, Noel.</span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span></div></div></div>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
@ 2019-08-02 14:35 jnc
  2019-08-02 15:01 ` Clem Cole
  2019-08-02 15:17 ` Arthur Krewat
  0 siblings, 2 replies; 16+ messages in thread
From: jnc @ 2019-08-02 14:35 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Arthur Krewat

    > there's the setuid bit on directories - otherwise known as the sticky
    > bit.

Minor nit; in V6 at least (not sure about later), the 'sticky' bit was a
separate bit from SUID and SGID. (When set on a pure/split object file, it
told the OS to retain the text image on the swap device even when no active
process was using it. Hence the name...)

	Noel


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 12:35 Doug McIlroy
  2019-08-01 16:22 ` John P. Linderman
  2019-08-01 17:01 ` Nemo Nusquam
@ 2019-08-01 21:23 ` Dave Horsfall
  2 siblings, 0 replies; 16+ messages in thread
From: Dave Horsfall @ 2019-08-01 21:23 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Thu, 1 Aug 2019, Doug McIlroy wrote:

> A common failing of Unix administration was a proliferation of suid-root 
> programs, e.g. mail(1). I recall one system that had a hundred such 
> programs. Sudo provided a way station between suid and ACLs.

I've always maintained that if you think you need setuid root (which is a 
gaping chest wound), you can invariably get away with setgid instead.

ObTrivia: Back in the 80s, some third-party software needed to be 
installed under "root".  I was suspicious, but I had little choice but to 
allow it (manager's orders; that company went under shortly after I left 
them).  Eventually I discovered why, when I had to clean up the mess: it 
actually *unlinked* directories; yes, you read that right...

-- Dave

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 18:26   ` Arthur Krewat
@ 2019-08-01 20:14     ` Lyndon Nerenberg
  0 siblings, 0 replies; 16+ messages in thread
From: Lyndon Nerenberg @ 2019-08-01 20:14 UTC (permalink / raw)
  To: tuhs

Two things killed off the adoption of groups as a widely-deployed
ACL mechanism:

1) NFS, specifically its limits on the number of supplimentary groups
   the protocol supported,

2) Kernel limits on the number of supplimentary groups associated with
   a process (e.g. NGROUPS_MAX)

--lyndon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 17:01 ` Nemo Nusquam
@ 2019-08-01 18:26   ` Arthur Krewat
  2019-08-01 20:14     ` Lyndon Nerenberg
  0 siblings, 1 reply; 16+ messages in thread
From: Arthur Krewat @ 2019-08-01 18:26 UTC (permalink / raw)
  To: tuhs

On 8/1/2019 1:01 PM, Nemo Nusquam wrote:
> On 08/01/19 08:35, Doug McIlroy wrote (in part):
>> Yet clean as the idea of groups
>> was, it has been used only sporadically (in my experience).
> Interesting... we used groups extensively (qa, staging, dev, research, 
> release, ...) but never ACLs.

I've had occasion to use groups extensively in various places I've 
consulted. Defense Contractors, educational institutions, etc. That, and 
quotas.

I've used Solaris ZFS ACLs, and Linux ACLs to solve many problems. 
There's always an exception to the UNIX rule when it comes to 
owner/group/world, and trying to corral users into that paradigm is not 
always fruitful.

Although, in one case, a common storage area with both the setgid and 
setuid bit on the parent, and various Engineering departments writing 
files and directories to it, was a really cool solution to a problem 
although it used secondary groups as well.

art k.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 12:35 Doug McIlroy
  2019-08-01 16:22 ` John P. Linderman
@ 2019-08-01 17:01 ` Nemo Nusquam
  2019-08-01 18:26   ` Arthur Krewat
  2019-08-01 21:23 ` Dave Horsfall
  2 siblings, 1 reply; 16+ messages in thread
From: Nemo Nusquam @ 2019-08-01 17:01 UTC (permalink / raw)
  To: tuhs

On 08/01/19 08:35, Doug McIlroy wrote (in part):
> Yet clean as the idea of groups
> was, it has been used only sporadically (in my experience).
Interesting... we used groups extensively (qa, staging, dev, research, 
release, ...) but never ACLs.

N.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 16:22 ` John P. Linderman
@ 2019-08-01 16:35   ` Arthur Krewat
  0 siblings, 0 replies; 16+ messages in thread
From: Arthur Krewat @ 2019-08-01 16:35 UTC (permalink / raw)
  To: tuhs

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

There's also the setgid bit on directories, that when files are created, 
they will be in the group that the parent directory has on it.

Also, I don't think it's been mentioned, but there's the setuid bit on 
directories - otherwise known as the sticky bit. When set, even if you 
have rights to "write" the directory (meaning, delete files), you can't 
delete those owned by other users. Useful for /tmp

I have no idea what the timeline is for either of these features :)


On 8/1/2019 12:22 PM, John P. Linderman wrote:
>
>     *Yet clean as the idea of groups was, it has been used only
>     sporadically (in my experience).*
>
>
> As I recall it, the original "basic groups" were essentially "us" and 
> "them". "Us" was everyone in the "in crowd", "them" was everyone else. 
> Since the basic groups were rather extensive, it was prudent to turn 
> group write permission off in your default umask. But that made groups 
> rather clunky. You were in only one group at a time, so you had to 
> "chgrp" to a select group, and then remember to set your umask to 
> allow group write permission so others in the group could modify 
> files. This changed when you could be in multiple groups at the same 
> time (a BSD invention?), and your primary group automatically changed 
> to the group owning your current working directory (iff you belonged 
> to that group). This made it unnecessary to do an explicit chgrp in 
> most cases. Having group write permission off in your default umask 
> was now a nuisance. We fixed that by giving everyone an unshared 
> primary group id, typically the same as the uid. It then became safe 
> to make group write permission on by default. This made groups much 
> more useful. Anyone in a group (but only those members) could create a 
> directory owned by that group, and group members working in that 
> directory defaulted to creating files (and subdirectories) group-owned 
> by and writable by all the members of the group. It just worked.
>


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

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    There's also the setgid bit on directories, that when files are
    created, they will be in the group that the parent directory has on
    it. <br>
    <br>
    Also, I don't think it's been mentioned, but there's the setuid bit
    on directories - otherwise known as the sticky bit. When set, even
    if you have rights to "write" the directory (meaning, delete files),
    you can't delete those owned by other users. Useful for /tmp<br>
    <br>
    I have no idea what the timeline is for either of these features :)<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 8/1/2019 12:22 PM, John P. Linderman
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <blockquote style="margin:0 0 0 40px;border:none;padding:0px">
          <div class="gmail_default" style="font-size:small"><b>Yet
              clean as the idea of groups was, it has been used only
              sporadically (in my experience).</b></div>
        </blockquote>
        <div><br>
        </div>
        A<span class="gmail_default" style="font-size:small">s I recall
          it, the original "basic groups" were essentially "us" and
          "them". "Us" was everyone in the "in crowd", "them" was
          everyone else. Since the basic groups were rather extensive,
          it was prudent to turn group write permission off in your
          default umask. But that made groups rather clunky. You were in
          only one group at a time, so you had to "chgrp" to a select
          group, and then remember to set your umask to allow group
          write permission so others in the group could modify files.
          This changed when you could be in multiple groups at the same
          time (a BSD invention?), and your primary group automatically
          changed to the group owning your current working directory
          (iff you belonged to that group). This made it unnecessary to
          do an explicit chgrp in most cases. Having group write
          permission off in your default umask was now a nuisance. We
          fixed that by giving everyone an unshared primary group id,
          typically the same as the uid. It then became safe to make
          group write permission on by default. This made groups much
          more useful. Anyone in a group (but only those members) could
          create a directory owned by that group, and group members
          working in that directory defaulted to creating files (and
          subdirectories) group-owned by and writable by all the members
          of the group. It just worked.</span></div>
      <br>
    </blockquote>
    <br>
  </body>
</html>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 12:35 Doug McIlroy
@ 2019-08-01 16:22 ` John P. Linderman
  2019-08-01 16:35   ` Arthur Krewat
  2019-08-01 17:01 ` Nemo Nusquam
  2019-08-01 21:23 ` Dave Horsfall
  2 siblings, 1 reply; 16+ messages in thread
From: John P. Linderman @ 2019-08-01 16:22 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

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

*Yet clean as the idea of groups was, it has been used only sporadically
(in my experience).*


As I recall it, the original "basic groups" were essentially "us" and
"them". "Us" was everyone in the "in crowd", "them" was everyone else.
Since the basic groups were rather extensive, it was prudent to turn group
write permission off in your default umask. But that made groups rather
clunky. You were in only one group at a time, so you had to "chgrp" to a
select group, and then remember to set your umask to allow group write
permission so others in the group could modify files. This changed when you
could be in multiple groups at the same time (a BSD invention?), and your
primary group automatically changed to the group owning your current
working directory (iff you belonged to that group). This made it
unnecessary to do an explicit chgrp in most cases. Having group write
permission off in your default umask was now a nuisance. We fixed that by
giving everyone an unshared primary group id, typically the same as the
uid. It then became safe to make group write permission on by default. This
made groups much more useful. Anyone in a group (but only those members)
could create a directory owned by that group, and group members working in
that directory defaulted to creating files (and subdirectories) group-owned
by and writable by all the members of the group. It just worked.

On Thu, Aug 1, 2019 at 8:36 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> Read and write permission were common ideas--even part of
> the Atlas paging hardware that was described before 1960.
> The original concept of time-sharing was to give a virtual
> computer to each user. When it became clear that sharing
> was an equally important aspect, owner/other permissions
> arose. I believe that was the case with Multics.
>
> Owner/other permissions were in PDP-11 Unix from the start.
> Group permissions arose from the ferment of daily talk in
> the Unix lab. How might the usual protections be extended
> to collaborative projects? Ken and Dennis deserve credit
> for the final implementation. Yet clean as the idea of groups
> was, it has been used only sporadically (in my experience).
>
> Execute permission (much overloaded in Unix) also dates
> back to the dawn of paging. One Unix innovation, due to
> Dennis, was the suid bit--the only patented feature in
> the Research system. It was instantly adopted for
> maintaining the Moo (a game now sold under the name
> "Master Mind") league standings table.
>
> One trouble with full-blown ACLs as required by NSA's
> Orange Book, is obscurity. It is hard (possibly NP-
> complete) to analyze the actual security of an ACL
> configuration.
>
> A common failing of Unix administration was a proliferation
> of suid-root programs, e.g. mail(1). I recall one system
> that had a hundred such programs. Sudo provided a way
> station between suid and ACLs.
>
> Doug
>

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

<div dir="ltr"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_default" style="font-size:small"><b>Yet clean as the idea of groups was, it has been used only sporadically (in my experience).</b></div></blockquote><div><br></div>A<span class="gmail_default" style="font-size:small">s I recall it, the original &quot;basic groups&quot; were essentially &quot;us&quot; and &quot;them&quot;. &quot;Us&quot; was everyone in the &quot;in crowd&quot;, &quot;them&quot; was everyone else. Since the basic groups were rather extensive, it was prudent to turn group write permission off in your default umask. But that made groups rather clunky. You were in only one group at a time, so you had to &quot;chgrp&quot; to a select group, and then remember to set your umask to allow group write permission so others in the group could modify files. This changed when you could be in multiple groups at the same time (a BSD invention?), and your primary group automatically changed to the group owning your current working directory (iff you belonged to that group). This made it unnecessary to do an explicit chgrp in most cases. Having group write permission off in your default umask was now a nuisance. We fixed that by giving everyone an unshared primary group id, typically the same as the uid. It then became safe to make group write permission on by default. This made groups much more useful. Anyone in a group (but only those members) could create a directory owned by that group, and group members working in that directory defaulted to creating files (and subdirectories) group-owned by and writable by all the members of the group. It just worked.</span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 1, 2019 at 8:36 AM Doug McIlroy &lt;<a href="mailto:doug@cs.dartmouth.edu">doug@cs.dartmouth.edu</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Read and write permission were common ideas--even part of<br>
the Atlas paging hardware that was described before 1960.<br>
The original concept of time-sharing was to give a virtual<br>
computer to each user. When it became clear that sharing<br>
was an equally important aspect, owner/other permissions<br>
arose. I believe that was the case with Multics.<br>
<br>
Owner/other permissions were in PDP-11 Unix from the start.<br>
Group permissions arose from the ferment of daily talk in<br>
the Unix lab. How might the usual protections be extended<br>
to collaborative projects? Ken and Dennis deserve credit<br>
for the final implementation. Yet clean as the idea of groups<br>
was, it has been used only sporadically (in my experience).<br>
<br>
Execute permission (much overloaded in Unix) also dates<br>
back to the dawn of paging. One Unix innovation, due to<br>
Dennis, was the suid bit--the only patented feature in<br>
the Research system. It was instantly adopted for <br>
maintaining the Moo (a game now sold under the name<br>
&quot;Master Mind&quot;) league standings table.<br>
<br>
One trouble with full-blown ACLs as required by NSA&#39;s<br>
Orange Book, is obscurity. It is hard (possibly NP-<br>
complete) to analyze the actual security of an ACL<br>
configuration.<br>
<br>
A common failing of Unix administration was a proliferation<br>
of suid-root programs, e.g. mail(1). I recall one system<br>
that had a hundred such programs. Sudo provided a way<br>
station between suid and ACLs.<br>
<br>
Doug<br>
</blockquote></div>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
@ 2019-08-01 12:35 Doug McIlroy
  2019-08-01 16:22 ` John P. Linderman
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Doug McIlroy @ 2019-08-01 12:35 UTC (permalink / raw)
  To: tuhs

Read and write permission were common ideas--even part of
the Atlas paging hardware that was described before 1960.
The original concept of time-sharing was to give a virtual
computer to each user. When it became clear that sharing
was an equally important aspect, owner/other permissions
arose. I believe that was the case with Multics.

Owner/other permissions were in PDP-11 Unix from the start.
Group permissions arose from the ferment of daily talk in
the Unix lab. How might the usual protections be extended
to collaborative projects? Ken and Dennis deserve credit
for the final implementation. Yet clean as the idea of groups
was, it has been used only sporadically (in my experience).

Execute permission (much overloaded in Unix) also dates
back to the dawn of paging. One Unix innovation, due to
Dennis, was the suid bit--the only patented feature in
the Research system. It was instantly adopted for 
maintaining the Moo (a game now sold under the name
"Master Mind") league standings table.

One trouble with full-blown ACLs as required by NSA's
Orange Book, is obscurity. It is hard (possibly NP-
complete) to analyze the actual security of an ACL
configuration.

A common failing of Unix administration was a proliferation
of suid-root programs, e.g. mail(1). I recall one system
that had a hundred such programs. Sudo provided a way
station between suid and ACLs.

Doug

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, back to index

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-01 23:43 [TUHS] Who's behind the UNIX filesystem permission jnc
2019-08-02  1:03 ` David Arnold
2019-08-02  4:36   ` Rob Pike
2019-08-07  2:35 ` Dave Horsfall
  -- strict thread matches above, loose matches on Subject: below --
2019-08-02 14:35 jnc
2019-08-02 15:01 ` Clem Cole
2019-08-02 15:17 ` Arthur Krewat
2019-08-02 21:23   ` Dave Horsfall
2019-08-03 12:51     ` Nemo
2019-08-01 12:35 Doug McIlroy
2019-08-01 16:22 ` John P. Linderman
2019-08-01 16:35   ` Arthur Krewat
2019-08-01 17:01 ` Nemo Nusquam
2019-08-01 18:26   ` Arthur Krewat
2019-08-01 20:14     ` Lyndon Nerenberg
2019-08-01 21:23 ` Dave Horsfall

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git