The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] History of chown semantics
@ 2014-01-10  1:41 Brian S Walden
  2014-01-10 13:17 ` scj
  0 siblings, 1 reply; 52+ messages in thread
From: Brian S Walden @ 2014-01-10  1:41 UTC (permalink / raw)


Yep, but where did the user base from PWB come from? They were
existing professional programmers from the mainframe world, still
writing for the mainframe, now sumbmitting via UNIX RJE.

Where did the sysadmins of PWB that added these users come from?
Same answer. If users are not added into the right groups, and
the users don't know (or need, care, or be able change) groups,
they don't get implemented properly.

And if you don't have gids, want to collaborate, and are discouraged
from copying, you need to do a ton of chown()s

> From: Larry McVoy <lm at bitmover.com>
> 
> > Now you are going to say this could all be done with proper use of group ids
> > and group permissions.  I agree, but in practice it was not done
> 
> Bzzt.  We have a solution, they should have used it.
> 



^ permalink raw reply	[flat|nested] 52+ messages in thread
* [TUHS] History of chown semantics
@ 2014-01-16  8:56 Brian S Walden
  0 siblings, 0 replies; 52+ messages in thread
From: Brian S Walden @ 2014-01-16  8:56 UTC (permalink / raw)


the short: yes you could chown your own files in 1st to 5th editions, the
first pwb was a derivition of 4th ed, so its not the originator of the idea.

the long:
that "superuser could not even chown setuid files" awoke a long dead memory.
I needed to go back to read the 1st ed man entries for chown(1) and (2)
again ( see http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html inc. below)
and it is documented that yes, one indeed could give away their
own files. also note 1st ed was pre-gid, files had only owner and
non-owner, so no setgid to worry about. looking more 2nd and 3rd ed
were the same (see ttp://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v2/v2man.pdf
and http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v3/v3man.tar.gz)
however in the 3rd ed there were now gids yet no restistions on chown of
setgid files.  4th and 5th ed still allowed file give away even if the
setuid bit was set by stripping that bit out (unless superuser) (but
did not strip the setgid bit)
(see http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v4/v4man.tar.gz 
and http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v5/v5man.pdf)
The 6th ed and on is when only the superuser could change file owners.
Since the first PWBs were derived from 4th and 5th editions, they just
did not buy into the new chown() restrictions from v6 (and added the
missed strippig of the setgid bit)

1st Ed manual enries --

11/3/71								CHOWN (I)
NAME		chown -- change owner
SYNOPSIS	chown owner file
DESCRIPTION	owner becomes the new owner of the files. The owner may be
		either a decimal UID or a name found in /etc/uids.
		Only the owner of a file is allowed to change the owner. It
		is illegal to change the owner of a file with the set-user-
		ID mode.
FILES		/etc/uids
SEE ALSO	stat
DIAGNOSTICS
BUGS
OWNER		ken, dmr

11/3/71							 SYS CHOWN (II)
NAME		chown -- change owner of file
SYNOPSIS	sys chown; name; owner / chown = 16.
DESCRIPTION	The file whose name is given by the null-terminated string
		pointed to by name has its owner changed to owner. Only
		the present owner of a file (or the super-user) may donate
		the file to another user. Also, one may not change the
		owner of a file with the set-user-ID bit on, otherwise one
		could create Trojan Horses able to misuse other's files.
FILES
SEE ALSO	/etc/uids has the mapping between user names and user
		numbers.
DIAGNOSTICS	The error bit (c-bit) is set on illegal owner changes.
BUGS
OWNER		ken, dmr


> From Doug McIlroy <doug at cs.dartmouth.edu>
> 
> Indeed, research Unix never allowed ordinary users to
> change a uid. And even in the first edition, the superuser
> was not allowed to do so on set-uid files, presumably to
> prevent inadvertent laying of cuckoo eggs. The v6 note
> about interaction with accounting reflected field
> experience with the overly liberal stance of other Unixes.
> 



^ permalink raw reply	[flat|nested] 52+ messages in thread
[parent not found: <mailman.1.1389661202.22836.tuhs@minnie.tuhs.org>]
* [TUHS] History of chown semantics
@ 2014-01-10 17:08 Brian S Walden
  0 siblings, 0 replies; 52+ messages in thread
From: Brian S Walden @ 2014-01-10 17:08 UTC (permalink / raw)


Yea, but that was all much later. It wasn't a problem with PWB as it's
file system structure, in practice, was /u[0-9]/{projectname}/{username}
so when a mount point ran low on space it wasn't the individual user that
got hassled, but the projects under the mount. Makes disc usage
accounting easy too, if it's under the project, the project pays for it.
You can see that structure and how PWB was actually used by a project at
http://9grid.org.uk/pwb/users-view.pdf

> From: Ed Carp <erc at pobox.com>
> 
> But it was fun to give away large files to someone else to avoid getting
> hassled by a sysadmin when you were close to filling up your disk quota.  :)



^ permalink raw reply	[flat|nested] 52+ messages in thread
* [TUHS] History of chown semantics
@ 2014-01-10 14:55 Brian S Walden
  2014-01-10 17:05 ` Ron Natalie
  0 siblings, 1 reply; 52+ messages in thread
From: Brian S Walden @ 2014-01-10 14:55 UTC (permalink / raw)


Very, very true. PWB was all about introducing UNIX into the comp
centers which were all ready in existance, with big iron sitting
in them.  Existing staff was tapped to run PWB as well, typically
consisted of operators, system administrators, system programmers,
program counselors, and accounting personal.  None were researchers,
UNIX was a service to be provided, the goal was to keep the machines
up and running to charge for usage.

> From: <scj at yaccman.com>
> 
> Recall that in those days, "systems administrator" was an entry level,
> minimum wage job.  Most worked third shift, and their primary duties were
> to mount and dismount disc backup tapes.  Those people who actually did
> administration in the sense we think of it were greatly underpaid and
> disrespected.  The next decade or two, particularly with networking,
> caused a huge change.  The Usenix LISA conferences did a lot to raise
> consciousness that there was a real there there.
> 



^ permalink raw reply	[flat|nested] 52+ messages in thread
* [TUHS] History of chown semantics
@ 2014-01-10  0:15 Brian S Walden
  2014-01-10  1:01 ` Larry McVoy
  0 siblings, 1 reply; 52+ messages in thread
From: Brian S Walden @ 2014-01-10  0:15 UTC (permalink / raw)


so RJE first, yes as written it did require that chown() work as non-root,
as it ran as the "rje" euid and did chown() files to the user's uid, I do
not believe that was the cause of the chown() semantics change, just a use
of it. iOne could do the same thing by other means (run as root, have a
setuid 0, file owner changer, etc) if chown(2) was root only. Why did I
believe that?

in section V.

    (iv) Make changes to the UNIX system only after much delibera-
         tion, and only when major gains can be made. Avoid chang-
         ing the UNIX system's interfaces, and isolate any such changes
         as much as possible. Stay close to the Research UNIX system,
         in order to take advantage of continuing improvements.

OK now lets look at a passage from VI --

    A good many UNIX (as opposed to PWB/UNIX) systems are run
    as "friendly-user" systems, and are each used by a fairly small
    number of people who often work closely together. A large frac-
    tion of these users have read/write permissions for most (or all)
    of the files on the system, have permission to add commands to
    the public directories, are capable of "re-booting" the operating
    system, and even know how to repair damaged file systems.
    The PWB/UNIX system, on the other hand, is most often found
    in a computer-center environment.

So the old way, no one even really needs chown() everybody had access to
everything.

then 8.1 

    The first major set of reliability improvements concerned the
    handling of disk files. It is a fact of life that time-sharing sys-
    tems are continually short of disk space; 
		...
    long-term tape backup copies, on the other hand, offer users the
    chance to delete files that they might want back at some time in
    the future, without requiring them to make "personal" copies

disk is always full, and users are discourged from making multiple copies
of f and even encourge to remove stuff you do not need right now and get
it from backup later, let alone making copies of someone else's files.

next from 8.4, while its abouttrying to solve the uid shortage
(only 256 at the time) it shows you the users' mind set, groups tended to
functionally operate as single user, but everyone still wanted a unique id.

   .... depended heavily on the
   characteristics of the PWB/UNIX user community, which, as mentioned
   above, consists mostly of groups of cooperating users,
   rather than of individual users working in isolation from one
   another. Typical behavior and opinions in these groups were:
      (i) Users in such a group cared very little about how much
          protection they had from each other, as long as their files
          were protected from damage by users outside their group.
     (ii) A common password was often used by members of a
          group, even when they owned distinct user-IDs. This was
          often done so that a needed file could be accessed without
          delay when its owner was unavailable.
     (iii) Most users were willing to have only one or two
           user-IDs per group, but wanted to retain their own login names
           and login directories.  We also favored such a distinction, because
           experience showed that the use of a single login name by
           more than a few users almost always produced cluttered
           directory structures containing useless files.

so the group members would know each othesr passwords (but there were many
groups on the same machine) thus non-root chown() become self-service in
sharing of files between group members, without the need of system
administrator involvment.  while one could give their files to someone
outside the group, it is not productive.

And then --

    to improve the security of files, a few commands were
    changed to create files with read/write permission for their own-
    ers, but read-only for everyone else. The net effect of these
    changes was to greatly enlarge the size of the user community
    that could be served, without destroying the convenience of the
    UNIX system and without requiring widespread and fundamental
    changes


shows the need to lock down file access, which means if you are sharing
in Research UNIX you did not need to chown() files, you could
just write them, but PWB will lock it down so a different group cannot
muck with it.

Now you are going to say this could all be done with proper use of group ids
and group permissions.  I agree, but in practice it was not done, as PWB
even consdidered the complete removal of gids, but only decided against it
as they would have to change too much software --

     considered was that of
     decreasing the available number of the so-called "group-IDs," or
     removing them entirely, and using the bits thus freed to increase
     the number of distinct user-IDs. Although attractive in many
     ways, this solution required a change in the interpretation of
     information stored with every single disk file (and every backup
     copy thereof), changes to large numbers of commands, and a fun-
     damental departure from the Research UNIX system during a time
     when thought was being given to possible changes to that
     system's protection mechanisms. For these reasons, this solution
     was deemed unwise.

> From: Clem Cole <clemc at ccc.com>
>
> Brian - I know the paper and Mash - the 3rd author and lived the times ;-)
> 
> I just don't see how having the ability to give away a file to some one
> else made it easier for anyone - system programmer or admin.   The idea of
> giving a device back begs the question of how did you get ownership in the
> first place.
> 
> The one thing I could think of was something like the RJE system that you
> would wanted to have made your files be owned by the RJE system, have them
> send it to the mainframe, get back information and then give the results
> back to you.   If they wanted to do that subsystem with out a root style
> privilege, you would need some way to give files away.
> 
> But I can think of other ways to do that without needing the chown(2) call
> to work with that semantic, so I really don't understand what it was used.
> 
> To me, it does not seem to be worth much.   As I said have to ask Mash if
> he remembers why it was considered a good idea.
> 
> Clem 



^ permalink raw reply	[flat|nested] 52+ messages in thread
* [TUHS] History of chown semantics
@ 2014-01-09 21:43 Doug McIlroy
  0 siblings, 0 replies; 52+ messages in thread
From: Doug McIlroy @ 2014-01-09 21:43 UTC (permalink / raw)


Indeed, research Unix never allowed ordinary users to
change a uid. And even in the first edition, the superuser
was not allowed to do so on set-uid files, presumably to
prevent inadvertent laying of cuckoo eggs. The v6 note
about interaction with accounting reflected field
experience with the overly liberal stance of other Unixes.



^ permalink raw reply	[flat|nested] 52+ messages in thread
* [TUHS] History of chown semantics
@ 2014-01-09 21:29 Brian S Walden
  2014-01-09 22:03 ` Clem Cole
  0 siblings, 1 reply; 52+ messages in thread
From: Brian S Walden @ 2014-01-09 21:29 UTC (permalink / raw)


it follows the philosophy of pwb --  a usable system for disparate small groups
of developers on the same hardware that could be managed by admins not
system programmers.

read http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-2177.pdf
for the flavor of that time, and you'll understand better.

> From: Clem Cole <clemc at ccc.com>
> 
> Brian - right as I showed in the code snippet from V6 and PWB.  The idea
> came into being with PWB.
> The question that is still open is why was it added/need in the first
> place?    I always thought is was a crazy/miss feature,
> 
> I think the argument is that if you owned the file, you should be allowed
> to give it to anyone else [including root] - but that actions opens up a
> number of issues (you pointed the big security one that was handled by
> and-ing off the SUID/SGID bits).  There are accounting issues as well as
> the practical one that Tim and I pointed out with importing of files on a
> tape.
> 
> As I said, the file give-away feature comes into UNIX with PWB, so I would
> ask Mash is he remembers why it was needed and why the SVID folks wanted
> it.  As I said, I personally found it not useful/a bad idea/miss-feature.
>  I remember that I soon after I learned about it/got bitten by the side
> effect, I ran into dmr  and srb at a USENIX and asked them about that a few
> other System III features that I found a little strange.   I don't remember
> much of the conversation.   But, if there are been a "good" reason I think
> I would have remembered it and not always thought it to be a bad idea.
> 
> Clem



^ permalink raw reply	[flat|nested] 52+ messages in thread
* [TUHS] History of chown semantics
@ 2014-01-09 19:23 Brian S Walden
  2014-01-09 19:51 ` Clem Cole
  0 siblings, 1 reply; 52+ messages in thread
From: Brian S Walden @ 2014-01-09 19:23 UTC (permalink / raw)


non-su chown worked in pwb, if the caller owned the file. code had to be
added then to the system call to strip the setuid/setgid bits if you were
not su, for obvious security reasons.  you didnt see that bit stripping
in, say the v6/v7 code.

> From: Tim Bradshaw <tfb at tfeb.org>
> 
> Sorry if this is off-topic but I bet someone here will know.
> 
> I recently had a significant surprise when I discovered that on HP-UX ordinary users can still give away files. Various of us who remember fairly old Unixes then sat around trying to remember which systems had this and where it came from: getting it almost entirely wrong, it turns out.
> 
> What we remembered was that it came from BSD, but this seems to be entirely wrong.  It looks like it originated with System III / V, and perhaps was imported from there into some SunOS (possibly it was in all versions before Solaris?) which is why we remember it as being in BSD.  It must have been in some 80s system or we would not remember it.  POSIX still allows it but clearly reluctantly.
> 
> So the questions are: (a) did it originate in System III or does it go back further than that, and (b) was it in the BSD-derived SunOSes or are we just making that up?
> 
> And I guess: who thought this was a good idea?
> 
> Thanks
> 
> --tim



^ permalink raw reply	[flat|nested] 52+ messages in thread
* [TUHS] History of chown semantics
@ 2014-01-09 10:59 Tim Bradshaw
  2014-01-09 12:46 ` Ronald Natalie
                   ` (2 more replies)
  0 siblings, 3 replies; 52+ messages in thread
From: Tim Bradshaw @ 2014-01-09 10:59 UTC (permalink / raw)


Sorry if this is off-topic but I bet someone here will know.

I recently had a significant surprise when I discovered that on HP-UX ordinary users can still give away files. Various of us who remember fairly old Unixes then sat around trying to remember which systems had this and where it came from: getting it almost entirely wrong, it turns out.

What we remembered was that it came from BSD, but this seems to be entirely wrong.  It looks like it originated with System III / V, and perhaps was imported from there into some SunOS (possibly it was in all versions before Solaris?) which is why we remember it as being in BSD.  It must have been in some 80s system or we would not remember it.  POSIX still allows it but clearly reluctantly.

So the questions are: (a) did it originate in System III or does it go back further than that, and (b) was it in the BSD-derived SunOSes or are we just making that up?

And I guess: who thought this was a good idea?

Thanks

--tim


^ permalink raw reply	[flat|nested] 52+ messages in thread
end of thread, other threads:[~2014-01-16  8:56 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-10  1:41 [TUHS] History of chown semantics Brian S Walden
2014-01-10 13:17 ` scj
2014-01-10 14:03   ` Ronald Natalie
  -- strict thread matches above, loose matches on Subject: below --
2014-01-16  8:56 Brian S Walden
     [not found] <mailman.1.1389661202.22836.tuhs@minnie.tuhs.org>
2014-01-14 22:44 ` Pepe
2014-01-15  1:33   ` Warner Losh
2014-01-15  1:43   ` Larry McVoy
2014-01-15  2:13     ` John Cowan
2014-01-15  4:02       ` Chris Nehren
2014-01-15  4:39         ` Steve Nickolas
2014-01-10 17:08 Brian S Walden
2014-01-10 14:55 Brian S Walden
2014-01-10 17:05 ` Ron Natalie
2014-01-10  0:15 Brian S Walden
2014-01-10  1:01 ` Larry McVoy
2014-01-10 15:16   ` Clem Cole
2014-01-10 15:21     ` Larry McVoy
2014-01-09 21:43 Doug McIlroy
2014-01-09 21:29 Brian S Walden
2014-01-09 22:03 ` Clem Cole
2014-01-10  0:59   ` John Cowan
2014-01-10  4:28   ` Greg 'groggy' Lehey
2014-01-10 10:15     ` Tim Bradshaw
2014-01-09 19:23 Brian S Walden
2014-01-09 19:51 ` Clem Cole
2014-01-09 10:59 Tim Bradshaw
2014-01-09 12:46 ` Ronald Natalie
2014-01-09 14:56   ` Clem Cole
2014-01-09 15:17     ` Tim Bradshaw
2014-01-09 15:31       ` Clem Cole
2014-01-09 18:18     ` Dario Niedermann
2014-01-09 18:31       ` Ron Natalie
2014-01-09 18:48         ` Clem Cole
2014-01-09 19:48           ` Armando Stettner
2014-01-09 19:52             ` Clem Cole
2014-01-09 18:37       ` Tim Bradshaw
2014-01-09 18:55       ` Warner Losh
2014-01-10 16:20     ` Ed Carp
2014-01-09 17:01 ` Jeremy C. Reed
2014-01-09 18:40   ` Clem Cole
2014-01-09 19:13   ` John Cowan
2014-01-09 20:19     ` Tim Newsham
2014-01-09 20:43       ` Warner Losh
2014-01-10 10:09     ` Tim Bradshaw
2014-01-10 17:18       ` John Cowan
2014-01-12 21:19         ` Tim Bradshaw
2014-01-13  7:05           ` John Cowan
2014-01-13 10:37             ` Tim Bradshaw
2014-01-13 16:15               ` John Cowan
2014-01-13 16:53                 ` SZIGETI Szabolcs
2014-01-13 18:16                   ` John Cowan
2014-01-09 22:57 ` Cyrille Lefevre

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).