From: tuhs@cuzuco.com (Brian S Walden)
Subject: [TUHS] History of chown semantics
Date: Thu, 16 Jan 2014 03:56:05 -0500 (EST) [thread overview]
Message-ID: <201401160856.s0G8u5fe021668@cuzuco.com> (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.
>
next reply other threads:[~2014-01-16 8:56 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 8:56 Brian S Walden [this message]
[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
-- strict thread matches above, loose matches on Subject: below --
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 1:41 Brian S Walden
2014-01-10 13:17 ` scj
2014-01-10 14:03 ` Ronald 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201401160856.s0G8u5fe021668@cuzuco.com \
--to=tuhs@cuzuco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).