The Unix Heritage Society mailing list
 help / color / Atom feed
* 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; 17+ 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] 17+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 12:35 [TUHS] Who's behind the UNIX filesystem permission Doug McIlroy
@ 2019-08-01 16:22 ` John P. Linderman
  2019-08-01 16:35   ` Arthur Krewat
  2019-08-02  8:35   ` [TUHS] Additional groups and additional directory permissions arnold
  2019-08-01 17:01 ` [TUHS] Who's behind the UNIX filesystem permission Nemo Nusquam
  2019-08-01 21:23 ` Dave Horsfall
  2 siblings, 2 replies; 17+ 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] 17+ 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
  2019-08-02  8:35   ` [TUHS] Additional groups and additional directory permissions arnold
  1 sibling, 0 replies; 17+ 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] 17+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 12:35 [TUHS] Who's behind the UNIX filesystem permission 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; 17+ 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] 17+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 17:01 ` [TUHS] Who's behind the UNIX filesystem permission Nemo Nusquam
@ 2019-08-01 18:26   ` Arthur Krewat
  2019-08-01 20:14     ` Lyndon Nerenberg
  0 siblings, 1 reply; 17+ 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] 17+ 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; 17+ 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] 17+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission
  2019-08-01 12:35 [TUHS] Who's behind the UNIX filesystem permission Doug McIlroy
  2019-08-01 16:22 ` John P. Linderman
  2019-08-01 17:01 ` [TUHS] Who's behind the UNIX filesystem permission Nemo Nusquam
@ 2019-08-01 21:23 ` Dave Horsfall
  2 siblings, 0 replies; 17+ 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] 17+ messages in thread

* [TUHS] Additional groups and additional directory permissions
  2019-08-01 16:22 ` John P. Linderman
  2019-08-01 16:35   ` Arthur Krewat
@ 2019-08-02  8:35   ` arnold
  2019-08-02 11:18     ` Tony Finch
                       ` (3 more replies)
  1 sibling, 4 replies; 17+ messages in thread
From: arnold @ 2019-08-02  8:35 UTC (permalink / raw)
  To: jpl.jpl, doug; +Cc: tuhs

[Subject line changed]

Hi.

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

I suspect this was true mainly at Research, where the whole place was
not large. Other people, as pointed out, found groups to be very useful.

"John P. Linderman" <jpl.jpl@gmail.com> wrote:
> This changed when you
> could be in multiple groups at the same time (a BSD invention?),

Yes, at 4.2 BSD. The so-called group set.

> and your
> primary group automatically changed to the group owning your current
> working directory (iff you belonged to that group).

No. Your process simply carried around a bunch of groups with it, and if
the group of the directory matched the primary group or a member of the
group set, you got group permission.

Arthur Krewat <krewat@kilonet.net>:
> 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.

IIRC this was a Sun invention. It was in SunOS 4.x, and may even have
been in SunOS 3.x.

> 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

Also a SunOS invention, IIRC.

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

Timeline is late 80s, SunOS 4.0, I believe. (Larry? :-)

These ideas later propogated into SVR4 / Solaris, Linux and most (if not all)
the other proprietary Unixes.

HTH,

Arnold

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

* Re: [TUHS] Additional groups and additional directory permissions
  2019-08-02  8:35   ` [TUHS] Additional groups and additional directory permissions arnold
@ 2019-08-02 11:18     ` Tony Finch
  2019-08-04  6:40       ` arnold
  2019-08-02 12:45     ` Arthur Krewat
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 17+ messages in thread
From: Tony Finch @ 2019-08-02 11:18 UTC (permalink / raw)
  To: arnold; +Cc: tuhs, doug

arnold@skeeve.com <arnold@skeeve.com> wrote:
> Arthur Krewat <krewat@kilonet.net>:
> > 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.
>
> IIRC this was a Sun invention. It was in SunOS 4.x, and may even have
> been in SunOS 3.x.

When Bill Joy added the "multi-group stuff" to BSD all directories became
implicitly set-gid:

https://svnweb.freebsd.org/csrg/sys/ufs/ffs/ffs_inode.c?r1=4818&r2=5855

This is in SCCS revision 4.8 so I think it appeared in 4.2BSD

As I understand it, when group support was improved in System V they did
not change creat() to match BSD but instead used the directory set-gid bit
to provide opt-in BSD semantics. I don't know if this was in Solaris or
earlier?

> > 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
>
> Also a SunOS invention, IIRC.

BSD again :-) SCCS revision 6.6 so I think it appeared in 4.3BSD

https://svnweb.freebsd.org/csrg/sys/ufs/ffs/ufs_lookup.c?r1=15809&r2=16046

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North
Channel: Variable 1 to 3, becoming easterly or southeasterly 2 to 4 later.
Smooth, occasionally slight at first in North Channel. Showers for a time near
shore. Good.

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

* Re: [TUHS] Additional groups and additional directory permissions
  2019-08-02  8:35   ` [TUHS] Additional groups and additional directory permissions arnold
  2019-08-02 11:18     ` Tony Finch
@ 2019-08-02 12:45     ` Arthur Krewat
  2019-08-02 13:06     ` Clem Cole
  2019-08-02 13:28     ` Clem Cole
  3 siblings, 0 replies; 17+ messages in thread
From: Arthur Krewat @ 2019-08-02 12:45 UTC (permalink / raw)
  To: tuhs



On 8/2/2019 4:35 AM, arnold@skeeve.com wrote:
> [Subject line changed]
>
> Hi.
>
> Arthur Krewat <krewat@kilonet.net>:
>> 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.
> IIRC this was a Sun invention. It was in SunOS 4.x, and may even have
> been in SunOS 3.x.
>
>> 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
> Also a SunOS invention, IIRC.
>
>> I have no idea what the timeline is for either of these features :)
> Timeline is late 80s, SunOS 4.0, I believe. (Larry? :-)
>
> These ideas later propogated into SVR4 / Solaris, Linux and most (if not all)
> the other proprietary Unixes.
>

Makes a lot of sense. I just fired up my Consensys SVR4.2 VirtualBox 
guest, and sure enough, neither the sticky bit, nor setgid work on 
directories.

My first commercial experience with UNIX as a consultant was SunOS. I 
had worked on Version 6 earlier, but that was purely personal and never 
more than messing around with a uVAX a friend had brought home from work.

thanks for the info!
art k.


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

* Re: [TUHS] Additional groups and additional directory permissions
  2019-08-02  8:35   ` [TUHS] Additional groups and additional directory permissions arnold
  2019-08-02 11:18     ` Tony Finch
  2019-08-02 12:45     ` Arthur Krewat
@ 2019-08-02 13:06     ` Clem Cole
  2019-08-02 13:28     ` Clem Cole
  3 siblings, 0 replies; 17+ messages in thread
From: Clem Cole @ 2019-08-02 13:06 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

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

On Fri, Aug 2, 2019 at 4:36 AM <arnold@skeeve.com> wrote:

> Arthur Krewat <krewat@kilonet.net>:
> > 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
>
> Also a SunOS invention, IIRC.
>
Nope, much older.  It was a BSDism -- Cory Hall 11/70 actually (V6
originally) - wnj probably, but it may have been somebody like Asa
Romberger or Bob Kriddle who were the admins.  VAXen distributions picked
it up and Sun got it from there.

[-- Attachment #2: Type: text/html, Size: 1334 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 4:36 AM &lt;<a href="mailto:arnold@skeeve.com">arnold@skeeve.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">Arthur Krewat &lt;<a href="mailto:krewat@kilonet.net" target="_blank">krewat@kilonet.net</a>&gt;:<br>&gt; Also, I don&#39;t think it&#39;s been mentioned, but there&#39;s the setuid bit on <br>
&gt; directories - otherwise known as the sticky bit. When set, even if you <br>
&gt; have rights to &quot;write&quot; the directory (meaning, delete files), you can&#39;t <br>
&gt; delete those owned by other users. Useful for /tmp<br>
<br>
Also a SunOS invention, IIRC.<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Nope, much older.  It was a BSDism -- Cory Hall 11/70 actually (V6 originally) - wnj probably, but it may have been somebody like Asa Romberger or Bob Kriddle who were the admins.</span> <span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> VAXen distributions picked it up and Sun got it from there.</span></div></div></div>

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

* Re: [TUHS] Additional groups and additional directory permissions
  2019-08-02  8:35   ` [TUHS] Additional groups and additional directory permissions arnold
                       ` (2 preceding siblings ...)
  2019-08-02 13:06     ` Clem Cole
@ 2019-08-02 13:28     ` Clem Cole
  2019-08-02 19:00       ` Thomas Paulsen
  3 siblings, 1 reply; 17+ messages in thread
From: Clem Cole @ 2019-08-02 13:28 UTC (permalink / raw)
  To: Aharon Robbins, Doug McIlroy; +Cc: The Eunuchs Hysterical Society

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

The best I can tell/remember is that groups went through 4 phases:
1.) No groups (earliest  UNIX) [ I personally never used this except in the
V0 retrocomputing]
2.) First group implementation (Thompson) [My first UNIX introduction was
with this implementation]
3.) PWB 1.0 (Mashey version) [then saw this post PWB]
4.) BSD 4.2 (wnj version) [and lived this transistion]

Each was a little different in semantics.

As Doug mentioned, many sites (like Research) really did not need much and
groups were really not used that widely.   Thompson added something like
the Project number of TOPS and some earlier systems.  Truth is, it did not
help much IMO.   It was useful for grouping things like the binaries and
keeping some more privileged programs from having to be setuid root.

Mashey added features in PWB, primarily because of the RJE/Front end to the
Mainframes and the need to have better protections/collections of certain
items.   But they still were much more like the DEC PPN, were you were
running as a single group (i.e. the tuple UID/GID).  This lasted a pretty
long time, as it worked reasonably well for larger academic systems, where
you had a user and were assigned a group, say for a course or class, you
might be talking.  If you looked at big 4.1 BSN Vaxen like at Purdue/Penn
State, *etc.*, that how they were admin'd.  But as Doug said, if you were
still a small site, the use of groups was still pretty shallow.

But, as part of the CSRG support for DARPA, there was a push from the
community to have a list of groups that a user could be a part and you
carried that list around in a more general manner.   The big sites, in
particular, were pushing for this because they were using groups as a major
feature.  wnj implemented same and it would go out widely in 4.2, although
>>by memory<< that was in 4.1B or 4.1C first.   It's possible Robert Elz
may have brought that to Bill with his quota changes, but frankly I've
forgotten.   There was a lot of work being done to the FS at that point,
much less Kirk's rewrite.

But as UNIX went back to workstations, the need for a more general group
system dropped away until the advent widely used distributed file systems
like CMU's AFS and Sun's NFS.  Then the concept of a user being in more
than one group became much more de rigeur even on a small machine.

Clem

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

<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The best I can tell/remember is that groups went through 4 phases:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">1.) No groups (earliest  UNIX) [ I personally never used this except in the V0 retrocomputing]</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">2.) First group implementation (Thompson) [My first UNIX introduction was with this implementation]</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">3.) PWB 1.0 (Mashey version) [then saw this post PWB]</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">4.) BSD 4.2 (wnj version) [and lived this transistion]</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Each was a little different in semantics. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">As Doug mentioned, many sites (like Research) really did not need much and groups were really not used that widely.   Thompson added something like the Project number of TOPS and some earlier systems.  Truth is, it did not help much IMO.   It was useful for grouping things like the binaries and keeping some more privileged programs from having to be setuid root.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Mashey added features in PWB, primarily because of the RJE/Front end to the Mainframes and the need to have better protections/collections of certain items.   But they still were much more like the DEC PPN, were you were running as a single group (i.e. the tuple UID/GID).  This lasted a pretty long time, as it worked reasonably well for larger academic systems, where you had a user and were assigned a group, say for a course or class, you might be talking.  If you looked at big 4.1 BSN Vaxen like at Purdue/Penn State, <i>etc.</i>, that how they were admin&#39;d.  But as Doug said, if you were still a small site, the use of groups was still pretty shallow.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">But, as part of the CSRG support for DARPA, there was a push from the community to have a list of groups that a user could be a part and you carried that list around in a more general manner.   The big sites, in particular, were pushing for this because they were using groups as a major feature.  wnj implemented same and it would go out widely in 4.2, although &gt;&gt;by memory&lt;&lt; that was in 4.1B or 4.1C first.   It&#39;s possible Robert Elz may have brought that to Bill with his quota changes, but frankly I&#39;ve forgotten.   There was a lot of work being done to the FS at that point, much less Kirk&#39;s rewrite.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">But as UNIX went back to workstations, the need for a more general group system dropped away until the advent widely used distributed file systems like CMU&#39;s AFS and Sun&#39;s NFS.  Then the concept of a user being in more than one group became much more de rigeur even on a small machine.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Clem</div></div>

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

* Re: [TUHS] Additional groups and additional directory permissions
  2019-08-02 13:28     ` Clem Cole
@ 2019-08-02 19:00       ` Thomas Paulsen
  0 siblings, 0 replies; 17+ messages in thread
From: Thomas Paulsen @ 2019-08-02 19:00 UTC (permalink / raw)
  To: Clem Cole; +Cc: tuhs

isn't Kirk McKusic a member of our group? Guess he can contribute a lot on this issue.

--- Ursprüngliche Nachricht ---
Von: Clem Cole <clemc@ccc.com>
Datum: 02.08.2019 15:28:18
An: Aharon Robbins <arnold@skeeve.com>, Doug McIlroy <doug@cs.dartmouth.edu>
Betreff: Re: [TUHS] Additional groups and additional directory permissions

> The best I can tell/remember is that groups went through 4 phases:
> 1.) No groups (earliest  UNIX) [ I personally never used this except in the
>
> V0 retrocomputing]
> 2.) First group implementation (Thompson) [My first UNIX introduction was
>
> with this implementation]
> 3.) PWB 1.0 (Mashey version) [then saw this post PWB]
> 4.) BSD 4.2 (wnj version) [and lived this transistion]
>
> Each was a little different in semantics.
>
> As Doug mentioned, many sites (like Research) really did not need much and
>
> groups were really not used that widely.   Thompson added something like
>
> the Project number of TOPS and some earlier systems.  Truth is, it did not
>
> help much IMO.   It was useful for grouping things like the binaries and
>
> keeping some more privileged programs from having to be setuid root.
>
> Mashey added features in PWB, primarily because of the RJE/Front end to the
>
> Mainframes and the need to have better protections/collections of certain
>
> items.   But they still were much more like the DEC PPN, were you were
> running as a single group (i.e. the tuple UID/GID).  This lasted a pretty
>
> long time, as it worked reasonably well for larger academic systems, where
>
> you had a user and were assigned a group, say for a course or class, you
>
> might be talking.  If you looked at big 4.1 BSN Vaxen like at Purdue/Penn
>
> State, *etc.*, that how they were admin'd.  But as Doug said, if you were
>
> still a small site, the use of groups was still pretty shallow.
>
> But, as part of the CSRG support for DARPA, there was a push from the
> community to have a list of groups that a user could be a part and you
> carried that list around in a more general manner.   The big sites, in
> particular, were pushing for this because they were using groups as a major
>
> feature.  wnj implemented same and it would go out widely in 4.2, although
>
> >>by memory<< that was in 4.1B or 4.1C first.   It's possible
> Robert Elz
> may have brought that to Bill with his quota changes, but frankly I've
> forgotten.   There was a lot of work being done to the FS at that point,
>
> much less Kirk's rewrite.
>
> But as UNIX went back to workstations, the need for a more general group
>
> system dropped away until the advent widely used distributed file systems
>
> like CMU's AFS and Sun's NFS.  Then the concept of a user being in more
> than one group became much more de rigeur even on a small machine.
>
> Clem
>



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

* Re: [TUHS] Additional groups and additional directory permissions
  2019-08-02 11:18     ` Tony Finch
@ 2019-08-04  6:40       ` arnold
  0 siblings, 0 replies; 17+ messages in thread
From: arnold @ 2019-08-04  6:40 UTC (permalink / raw)
  To: dot, arnold; +Cc: tuhs, doug

> arnold@skeeve.com <arnold@skeeve.com> wrote:
> > Arthur Krewat <krewat@kilonet.net>:
> > > 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.
> >
> > IIRC this was a Sun invention. It was in SunOS 4.x, and may even have
> > been in SunOS 3.x.

Tony Finch <dot@dotat.at> wrote:
> When Bill Joy added the "multi-group stuff" to BSD all directories became
> implicitly set-gid:

Yes.  But the commercial world had backwards compatibility to worry about.
Thus the setgid bit on directories. I'm no longer sure who first came
up with it.

> As I understand it, when group support was improved in System V they did
> not change creat() to match BSD but instead used the directory set-gid bit
> to provide opt-in BSD semantics. I don't know if this was in Solaris or
> earlier?

Correct, but not sure when it was first done.

> > > 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
> >
> > Also a SunOS invention, IIRC.
>
> BSD again :-) SCCS revision 6.6 so I think it appeared in 4.3BSD

That sounds right. I stand corrected.

Thanks,

Arnold

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

* Re: [TUHS] Additional groups and additional directory permissions
  2019-08-10  4:02 Kirk McKusick
@ 2019-08-10  6:02 ` Thomas Paulsen
  0 siblings, 0 replies; 17+ messages in thread
From: Thomas Paulsen @ 2019-08-10  6:02 UTC (permalink / raw)
  To: Kirk McKusick; +Cc: tuhs

thanks a lot!

--- Ursprüngliche Nachricht ---
Von: Kirk McKusick <mckusick@mckusick.com>
Datum: 10.08.2019 06:02:51
An: Clem Cole <clemc@ccc.com>
Betreff: Re: [TUHS] Additional groups and additional directory permissions

>
> Late to answer...
>
> As far as I remember, Clem's description is correct. The filesystem
> itself stores only one owner and one group ID. When checking access
> to the file, the file owner is checked to see if the user ID matches.
> If so, then the owner permissions are applied. If not then the group
> array associated with the user is used to decide if the group of the
> file matches one of the groups of which the user is a member and if
> so the group permissions apply. Otherwise the other permissions are
> used.
>
> In BSD, the group assigned to the file is assigned from the group of
> the directory in which it is created. The setgid flag can be set only
> if that group is a member of the user's group array. The user can only
> change the group ID to one that appears in their group array.
>
> Until multiple group sets were added to System V, the group of the
> file was taken from the gid assigned to the user at login.
>
> 	Kirk McKusick
>



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

* Re: [TUHS] Additional groups and additional directory permissions
@ 2019-08-10  4:02 Kirk McKusick
  2019-08-10  6:02 ` Thomas Paulsen
  0 siblings, 1 reply; 17+ messages in thread
From: Kirk McKusick @ 2019-08-10  4:02 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

> Date: Fri, 2 Aug 2019 09:28:18 -0400
> From: Clem Cole <clemc@ccc.com>
> To: Aharon Robbins <arnold@skeeve.com>, Doug McIlroy <doug@cs.dartmouth.edu>
> Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
> Subject: Re: [TUHS] Additional groups and additional directory permissions
> 
> The best I can tell/remember is that groups went through 4 phases:
> 1.) No groups (earliest  UNIX) [ I personally never used this except in the
> V0 retrocomputing]
> 2.) First group implementation (Thompson) [My first UNIX introduction was
> with this implementation]
> 3.) PWB 1.0 (Mashey version) [then saw this post PWB]
> 4.) BSD 4.2 (wnj version) [and lived this transistion]
> 
> Each was a little different in semantics.
> 
> As Doug mentioned, many sites (like Research) really did not need much and
> groups were really not used that widely.   Thompson added something like
> the Project number of TOPS and some earlier systems.  Truth is, it did not
> help much IMO.   It was useful for grouping things like the binaries and
> keeping some more privileged programs from having to be setuid root.
> 
> Mashey added features in PWB, primarily because of the RJE/Front end to the
> Mainframes and the need to have better protections/collections of certain
> items.   But they still were much more like the DEC PPN, were you were
> running as a single group (i.e. the tuple UID/GID).  This lasted a pretty
> long time, as it worked reasonably well for larger academic systems, where
> you had a user and were assigned a group, say for a course or class, you
> might be talking.  If you looked at big 4.1 BSN Vaxen like at Purdue/Penn
> State, *etc.*, that how they were admin'd.  But as Doug said, if you were
> still a small site, the use of groups was still pretty shallow.
> 
> But, as part of the CSRG support for DARPA, there was a push from the
> community to have a list of groups that a user could be a part and you
> carried that list around in a more general manner.   The big sites, in
> particular, were pushing for this because they were using groups as a major
> feature.  wnj implemented same and it would go out widely in 4.2, although
> >>by memory<< that was in 4.1B or 4.1C first.   It's possible Robert Elz
> may have brought that to Bill with his quota changes, but frankly I've
> forgotten.   There was a lot of work being done to the FS at that point,
> much less Kirk's rewrite.
> 
> But as UNIX went back to workstations, the need for a more general group
> system dropped away until the advent widely used distributed file systems
> like CMU's AFS and Sun's NFS.  Then the concept of a user being in more
> than one group became much more de rigeur even on a small machine.
> 
> Clem

Late to answer...

As far as I remember, Clem's description is correct. The filesystem
itself stores only one owner and one group ID. When checking access
to the file, the file owner is checked to see if the user ID matches.
If so, then the owner permissions are applied. If not then the group
array associated with the user is used to decide if the group of the
file matches one of the groups of which the user is a member and if
so the group permissions apply. Otherwise the other permissions are
used.

In BSD, the group assigned to the file is assigned from the group of
the directory in which it is created. The setgid flag can be set only
if that group is a member of the user's group array. The user can only
change the group ID to one that appears in their group array.

Until multiple group sets were added to System V, the group of the
file was taken from the gid assigned to the user at login.

	Kirk McKusick

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

* Re: [TUHS] Additional groups and additional directory permissions
@ 2019-08-02 19:44 Norman Wilson
  0 siblings, 0 replies; 17+ messages in thread
From: Norman Wilson @ 2019-08-02 19:44 UTC (permalink / raw)
  To: tuhs

Thomas Paulsen:

  isn't Kirk McKusic a member of our group?

====

Kirk is a member of many groups, all at the same time.

Norman Wilson
Toronto ON

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

end of thread, back to index

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-01 12:35 [TUHS] Who's behind the UNIX filesystem permission Doug McIlroy
2019-08-01 16:22 ` John P. Linderman
2019-08-01 16:35   ` Arthur Krewat
2019-08-02  8:35   ` [TUHS] Additional groups and additional directory permissions arnold
2019-08-02 11:18     ` Tony Finch
2019-08-04  6:40       ` arnold
2019-08-02 12:45     ` Arthur Krewat
2019-08-02 13:06     ` Clem Cole
2019-08-02 13:28     ` Clem Cole
2019-08-02 19:00       ` Thomas Paulsen
2019-08-01 17:01 ` [TUHS] Who's behind the UNIX filesystem permission Nemo Nusquam
2019-08-01 18:26   ` Arthur Krewat
2019-08-01 20:14     ` Lyndon Nerenberg
2019-08-01 21:23 ` Dave Horsfall
2019-08-02 19:44 [TUHS] Additional groups and additional directory permissions Norman Wilson
2019-08-10  4:02 Kirk McKusick
2019-08-10  6:02 ` Thomas Paulsen

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