The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Groups origins
@ 2021-10-03 22:10 Norman Wilson
  2021-10-04 13:39 ` John P. Linderman
  0 siblings, 1 reply; 5+ messages in thread
From: Norman Wilson @ 2021-10-03 22:10 UTC (permalink / raw)
  To: tuhs

I can't speak to the evolution and use of specific
groups; I suspect it was all ad-hoc early on.

Groups appeared surprisingly late (given how familiar
they seem now): they don't show up in the manual
until the Sixth Edition.  Before that, chown took
only two arguments (filename and owner), and
permission modes had three bits fewer.

I forget how it came up, but the late Lee McMahon
once told me an amusing story about their origin:

Ken announced that he was adding groups.

Lee asked what they were for.

Ken replied with a shrug and `I dunno.'

Norman Wilson
Toronto ON

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

* Re: [TUHS] Groups origins
  2021-10-03 22:10 [TUHS] Groups origins Norman Wilson
@ 2021-10-04 13:39 ` John P. Linderman
  0 siblings, 0 replies; 5+ messages in thread
From: John P. Linderman @ 2021-10-04 13:39 UTC (permalink / raw)
  To: Norman Wilson; +Cc: The Eunuchs Hysterical Society

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

Having roots in the more "businessy" areas of the Labs, groups made sense
for a collection of people working on the same project. You wanted everyone
in the group to be able to create files and directories, but not people
outside the group, less because you didn't trust most of the people sharing
a machine than because you didn't want accidental destruction from outside.
But the newgroup command for acting as a member of the group was clunky.
Use of groups for this purpose didn't become practical until 1) you could
be members of multiple groups simultaneously and 2) the group ownership of
newly created files and directories would be that of the directory in which
they were created, if you were a member of that group. Of course, this
meant your umask should confer group write permission by default, which
didn't work well if your primary group was widely shared. So we adopted the
policy of everyone having a primary group with the same id as your user id.
"Private" files and directories were not group-modifiable by anyone other
than yourself, but "project" files were modifiable by anyone in the project
group. This made groups work seamlessly. Just do a chgrp on a directory
where group sharing was to be done, and everything just worked thereafter.

On Sun, Oct 3, 2021 at 6:12 PM Norman Wilson <norman@oclsc.org> wrote:

> I can't speak to the evolution and use of specific
> groups; I suspect it was all ad-hoc early on.
>
> Groups appeared surprisingly late (given how familiar
> they seem now): they don't show up in the manual
> until the Sixth Edition.  Before that, chown took
> only two arguments (filename and owner), and
> permission modes had three bits fewer.
>
> I forget how it came up, but the late Lee McMahon
> once told me an amusing story about their origin:
>
> Ken announced that he was adding groups.
>
> Lee asked what they were for.
>
> Ken replied with a shrug and `I dunno.'
>
> Norman Wilson
> Toronto ON
>

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

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

* [TUHS] Groups origins
@ 2021-10-04  1:22 Norman Wilson
  0 siblings, 0 replies; 5+ messages in thread
From: Norman Wilson @ 2021-10-04  1:22 UTC (permalink / raw)
  To: tuhs

  Groups appeared surprisingly late (given how familiar
  they seem now): they don't show up in the manual
  until the Sixth Edition.

Mea culpa; read too hastily.  The change actually
came with the Fourth Edition, at the same time as
several other landmark system changes:
-- Time changing from a 32-bit count of 60Hz clock
ticks (which ran out so quickly that its epoch kept
moving) to the modern 32 bits of whole seconds, based
at 1970-01-01T00:00:00 GMT (which takes much longer
to run out, though the horizon is now visible).
-- The modern super-block.  In 4/e, the super-block
began at block 0, not 1 (so bootstrapping was rather
more complicated); the free list was a bitmap rather
than the later list of blocks containing lists of
free block numbers.
-- The super-block contained a bitmap of free
i-numbers too.  All told, the free block and free
i-node map made up a 1024-byte super-block.
-- I-numbers 1-40 were device files; the root
directory was i-number 41.  The only file-type
indication in the mode word was a single bit to
denote directory.

It was already clear that the lifetime of the
bitmaps was running out: the BUGS section says
two blocks isn't enough for the bitmaps for a
20-megabyte RP02.

Norman Wilson
Toronto ON

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

* Re: [TUHS] Groups origins
  2021-10-03 21:54 Will Senn
@ 2021-10-03 23:22 ` Warner Losh
  0 siblings, 0 replies; 5+ messages in thread
From: Warner Losh @ 2021-10-03 23:22 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

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

On Sun, Oct 3, 2021 at 3:55 PM Will Senn <will.senn@gmail.com> wrote:

> Hi all,
>
> I was reading a recent thread, over on the FreeBSD forums about groups
> that quickly devolved into a discussion on the origin of the operator group:
> https://forums.freebsd.org/threads/groups-overview.82303/
>
> I thought y’all would be the best place to ask the questions that arose in
> me during my read of the thread.
>
> Here they are in no special order:
>
> 1. Where did operator come from and what was it intended to solve?
>

Operator was for people that 'operated' the computers. The name came from a
group on TOPS-20. The operator could do things normal users couldn't, like
restart stalled print jobs, run backups to mag tape and a few other normal
'house keeping' duties that these old machines needed.

In BSD, it serves much the same purpose. It's a way to grant a little bit
of privilege to an otherwise normal account that falls short of root.

This grew out of the days before the personal computer revolution where the
machine was massive (in terms of size), served a lot of people (via dumb
terminals), and needed constant care and feeding that you'd delegate to
undergrad technitians who needed work study money...


> 2. How has it evolved.
>

In general, using groups to control permissions has fallen out of style.
There's a few around still like operator and wheel that control some
things, or have elevated privs due to being able to open files others can't.


> 3. What’s a good place to look/ref to read about groups, generally?
>

At one point, it was well documented in the FreeBSD handbook, but I'm not
seeing it right away in a quick search.


> I liked one respondent’s answer about using find, heir, and the files
> themselves to learn about groups being used in a running system, paying
> attention to the owner, Audi, etc along the way and this is how I do it
> now, but this approach doesn’t account for the history and evolution.
>
> Thanks!
>
> Willu
>
>
>
> Sent from my iPhone
>

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

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

* [TUHS] Groups origins
@ 2021-10-03 21:54 Will Senn
  2021-10-03 23:22 ` Warner Losh
  0 siblings, 1 reply; 5+ messages in thread
From: Will Senn @ 2021-10-03 21:54 UTC (permalink / raw)
  To: tuhs

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

Hi all,

I was reading a recent thread, over on the FreeBSD forums about groups that quickly devolved into a discussion on the origin of the operator group:
https://forums.freebsd.org/threads/groups-overview.82303/

I thought y’all would be the best place to ask the questions that arose in me during my read of the thread. 

Here they are in no special order:

1. Where did operator come from and what was it intended to solve?
2. How has it evolved.
3. What’s a good place to look/ref to read about groups, generally?

I liked one respondent’s answer about using find, heir, and the files themselves to learn about groups being used in a running system, paying attention to the owner, Audi, etc along the way and this is how I do it now, but this approach doesn’t account for the history and evolution.

Thanks!

Willu



Sent from my iPhone

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

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

end of thread, other threads:[~2021-10-04 13:41 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-03 22:10 [TUHS] Groups origins Norman Wilson
2021-10-04 13:39 ` John P. Linderman
  -- strict thread matches above, loose matches on Subject: below --
2021-10-04  1:22 Norman Wilson
2021-10-03 21:54 Will Senn
2021-10-03 23:22 ` Warner Losh

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ https://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index 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