[TUHS] History of chown semantics

[TUHS] History of chown semantics

[Brian S Walden]

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

[TUHS] History of chown semantics

[Ron Natalie]

Hell, we were all undergraduates at JHU running the UNIX facility and it
wasn't no unskilled position in the pre-fsck days.
I remember having to describe the filesystem in detail and the vagaries of
icheck and dcheck before I got the job.
We never ran PWB UNIX directly (having our own heavily hacked V6 kernel) but
we picked and chose from the various distributions
(PWB, V7).   I remember the pwb shell.

My first after graduation job (while waiting for my clearance) was helping
the QA guys set up sccs and many other things that came along with PWB so we
could manage the project software controls not for any of the IBM operating
systems but for RSX-11/M.

[TUHS] History of chown semantics

[Brian S Walden]

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

[TUHS] History of chown semantics

[Steve Nickolas]

On Tue, 14 Jan 2014, Chris Nehren wrote:

> On Tue, Jan 14, 2014 at 21:13:55 -0500, John Cowan wrote:
>> Larry McVoy scripsit:
>>
>>> But with disk so bloody cheap and VMs working so bloody well, it's pretty
>>> easy to spin up a VM and give it to some idiot who thinks they need root.
>>
>> ./configure or not, it's damned hard to install large amounts of software
>> without root.  You can do it, but it's hard, especially if some of it
>> is really really expensive to build from source, since you're blocked
>> from using the distro's own install tool.
>
> How is this difficult? I've not had any problems that are
> specific to the software not wanting to be installed as non-root.
> You need to know some compiler flags like -R and ./configure
> variables like CFLAGS and LDFLAGS, but other than that I've not
> seen any problems that really stick out in my memory.
>
>> Most people who use Unix today are the only ones there.  Someone should
>> really rewrite finger(1) to do something different.
>
> What do you do that this is the case? I'd literally be out of a
> job if I didn't have a gaggle of users to look after. And so
> would my entire team of coworkers. This is such a bewildering
> claim to me and everyone I know that we can't fathom how it's
> true.
>
>

You'd be surprised.  Over on hoshinet, we actually share Linux and FreeBSD 
servers among each other.  My virtual root has 2 actual users and the 
server it's hosted on has 4 actual users.

-uso.

[TUHS] History of chown semantics

[Chris Nehren]

On Tue, Jan 14, 2014 at 21:13:55 -0500, John Cowan wrote:
> Larry McVoy scripsit:
> 
> > But with disk so bloody cheap and VMs working so bloody well, it's pretty
> > easy to spin up a VM and give it to some idiot who thinks they need root.
> 
> ./configure or not, it's damned hard to install large amounts of software
> without root.  You can do it, but it's hard, especially if some of it
> is really really expensive to build from source, since you're blocked
> from using the distro's own install tool.

How is this difficult? I've not had any problems that are
specific to the software not wanting to be installed as non-root.
You need to know some compiler flags like -R and ./configure
variables like CFLAGS and LDFLAGS, but other than that I've not
seen any problems that really stick out in my memory.

> Most people who use Unix today are the only ones there.  Someone should
> really rewrite finger(1) to do something different.

What do you do that this is the case? I'd literally be out of a
job if I didn't have a gaggle of users to look after. And so
would my entire team of coworkers. This is such a bewildering
claim to me and everyone I know that we can't fathom how it's
true.

-- 
Chris Nehren

[TUHS] History of chown semantics

[John Cowan]

Larry McVoy scripsit:

> But with disk so bloody cheap and VMs working so bloody well, it's pretty
> easy to spin up a VM and give it to some idiot who thinks they need root.

./configure or not, it's damned hard to install large amounts of software
without root.  You can do it, but it's hard, especially if some of it
is really really expensive to build from source, since you're blocked
from using the distro's own install tool.

> You know what it reminds me of?  Eunice on a VAX running VMS.  It seems like
> Unix but you're the only one there.  Sort of lonely.  I liked running who
> and seeing a bunch of people logged in.  Run finger $boss and see if he 
> read your email.

Most people who use Unix today are the only ones there.  Someone should
really rewrite finger(1) to do something different.

-- 
John Cowan     http://ccil.org/~cowan    cowan at ccil.org
Monday we watch-a Firefly's house, but he no come out.  He wasn't home.
Tuesday we go to the ball game, but he fool us.  He no show up.  Wednesday he
go to the ball game, and we fool him.  We no show up.  Thursday was a
double-header.  Nobody show up.  Friday it rained all day.  There was no ball
game, so we stayed home and we listened to it on-a the radio.  --Chicolini

[TUHS] History of chown semantics

[Larry McVoy]

On Tue, Jan 14, 2014 at 11:44:22PM +0100, Pepe wrote:
> What is "dead as the dodo" is multi-user shell access. But that does not
> mean
> multi-user shell access should be removed from modern systems, no matter how
> dead it may be.

It's not dead, it's just pining :)

I think organizations with a clue buy the biggest boxes they can and allow
multi user access for devs.

But with disk so bloody cheap and VMs working so bloody well, it's pretty
easy to spin up a VM and give it to some idiot who thinks they need root.

You know what it reminds me of?  Eunice on a VAX running VMS.  It seems like
Unix but you're the only one there.  Sort of lonely.  I liked running who
and seeing a bunch of people logged in.  Run finger $boss and see if he 
read your email.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[TUHS] History of chown semantics

[Warner Losh]

On Jan 14, 2014, at 3:44 PM, Pepe wrote:

> On Tuesday, January 14, 2014 2:00 AM [GMT+1=CET], John Cowan wrote:
> 
>> SZIGETI Szabolcs scripsit:
>> 
>>> Well, with the same reasoning, we don't need passwords or protection
>>> bits on files, since I can always take a piece of steel pipe and
>>> beat the owner, until he gives out the data, so why bother?
>> 
>> More like beating my argument with a pipe than the owner.
>> 
>>> Blocking chown for general users is one level of several controls.
>> 
>> Its specific purpose was to make per-user quotas practical, but since
>> per-user quotas are as dead as the dodo, it no longer serves any known
>> purpose.
> 
> I don't think quotas are dead. It seems nowadays the "preferred" storage
> backend for email on Unix/Linux mail servers is Maildir, and Maildir uses
> the
> filesystem as its own backend, together with the filesystem's quota facility
> to give or take storage space to/from mailboxes -- yes, provided the users
> are real system users and not "virtual users", but still.
> 
> What is "dead as the dodo" is multi-user shell access. But that does not
> mean
> multi-user shell access should be removed from modern systems, no matter how
> dead it may be.

Because it really isn't dead. Developers still use it.

Warner

[TUHS] History of chown semantics

[Pepe]

On Tuesday, January 14, 2014 2:00 AM [GMT+1=CET], John Cowan wrote:

> SZIGETI Szabolcs scripsit:
>
> > Well, with the same reasoning, we don't need passwords or protection
> > bits on files, since I can always take a piece of steel pipe and
> > beat the owner, until he gives out the data, so why bother?
>
> More like beating my argument with a pipe than the owner.
>
> > Blocking chown for general users is one level of several controls.
>
> Its specific purpose was to make per-user quotas practical, but since
> per-user quotas are as dead as the dodo, it no longer serves any known
> purpose.

I don't think quotas are dead. It seems nowadays the "preferred" storage
backend for email on Unix/Linux mail servers is Maildir, and Maildir uses
the
filesystem as its own backend, together with the filesystem's quota facility
to give or take storage space to/from mailboxes -- yes, provided the users
are real system users and not "virtual users", but still.

What is "dead as the dodo" is multi-user shell access. But that does not
mean
multi-user shell access should be removed from modern systems, no matter how
dead it may be.


-Pepe.

[TUHS] History of chown semantics

[John Cowan]

SZIGETI Szabolcs scripsit:

> Well, with the same reasoning, we don't need passwords or protection
> bits on files, since I can always take a piece of steel pipe and beat
> the owner, until he gives out the data, so why bother?

More like beating my argument with a pipe than the owner.

> Blocking chown for general users is one level of several controls. 

Its specific purpose was to make per-user quotas practical, but since
per-user quotas are as dead as the dodo, it no longer serves any known
purpose.  Yes, it blocks a particularly crude substitute for MAC in the
now-unusual case of true timesharing as opposed to single-user clients
and single-purpose servers.  But really it is nothing but security by
ceremonial.  A better case could be made that it should require root
privilege to perform chmod, or at least any chmod that widens access.

-- 
You are a child of the universe no less         John Cowan
than the trees and all other acyclic            http://www.ccil.org/~cowan
graphs; you have a right to be here.            cowan at ccil.org
  --DeXiderata by Sean McGrath

[TUHS] History of chown semantics

[SZIGETI Szabolcs]

Well, with the same reasoning, we don't need passwords or protection bits
on files, since I can always take a piece of steel pipe and beat the owner,
until he gives out the data, so why bother?

Blocking chown for general users is one level of several controls. Given
the need, it is always possible to thwart an attack, with additional
controls. And of course, given a set of controls, is is always possible to
find an attack that will be successful. It all depends on the cost of the
protection, the attack and of the data being protected.

Szabolcs





2014/1/13 John Cowan <cowan at mercury.ccil.org>

> Tim Bradshaw scripsit:
>
> > For instance imagine I want to pass some customer data to which I have
> > access to you, who con't have access, for purposes of malice.
>
> Download the file and mail it to me via anonymous remailer.  Failing
> that, use your cell and take snapshots of the screen.  Failing that,
> write down the data with pen and ink and send it by snail mail.
>
> If I own a file, I can always get the contents to you one way or another.
> Blocking chown doesn't help.
>
> --
> Let's face it: software is crap. Feature-laden and bloated, written under
> tremendous time-pressure, often by incapable coders, using dangerous
> languages and inadequate tools, trying to connect to heaps of broken or
> obsolete protocols, implemented equally insufficiently, running on
> unpredictable hardware -- we are all more than used to brokenness.
>                    --Felix Winkelmann
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140113/3b8dafa0/attachment.html>

[TUHS] History of chown semantics

[John Cowan]

Tim Bradshaw scripsit:

> For instance imagine I want to pass some customer data to which I have
> access to you, who con't have access, for purposes of malice.  

Download the file and mail it to me via anonymous remailer.  Failing
that, use your cell and take snapshots of the screen.  Failing that,
write down the data with pen and ink and send it by snail mail.

If I own a file, I can always get the contents to you one way or another.
Blocking chown doesn't help.

-- 
Let's face it: software is crap. Feature-laden and bloated, written under
tremendous time-pressure, often by incapable coders, using dangerous
languages and inadequate tools, trying to connect to heaps of broken or
obsolete protocols, implemented equally insufficiently, running on
unpredictable hardware -- we are all more than used to brokenness.
                   --Felix Winkelmann

[TUHS] History of chown semantics

[Tim Bradshaw]

I think that this is off-topic now, so I won't respond further in this thread.

> Which is to say, the file owner is irrelevant to the quota system, only
> the pathname matters.

Indeed, *because that's the only way you can do it without quotas*, which was my whole point.

> Again, how can any of this be corrupted by free chown-ing?  

For instance imagine I want to pass some customer data to which I have access to you, who con't have access, for purposes of malice.  I know that leaving a world-readable file will be spotted.  So I put them in a file which is 600 in /tmp, and chown it to you.  Not only can't this be easily spotted without system-call auditing (which people generally do not do), but if it is spotted it looks like it's your fault since you own the file.  File ownership does matter.

[TUHS] History of chown semantics

[John Cowan]

Tim Bradshaw scripsit:

> Quotas actually don't seem to be used very much.  Instead people
> Greenspun it by confining applications to distinct filesystems and
> some kind of volume manager.  

Which is to say, the file owner is irrelevant to the quota system, only
the pathname matters.

> Privilege separation is more sorted out.  People (regulators, auditors,
> the organisation itself) are extremely interested in knowing who can
> see and do what.  Root access seems to be typically pretty sorted by now
> (no-one has it except under some kind of auditable breakglass process)
> and controlling per-user access is getting tied down where it hasn't
> been, usually by elaborate sudo rules for the various role users
> (unix admin, oracle admin, business users etc).  

Again, how can any of this be corrupted by free chown-ing?  

-- 
Some people open all the Windows;       John Cowan
wise wives welcome the spring           cowan at ccil.org
by moving the Unix.                     http://www.ccil.org/~cowan
  --ad for Unix Book Units (U.K.)
        (see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif)

[TUHS] History of chown semantics

[Tim Bradshaw]

On 10 Jan 2014, at 17:18, John Cowan wrote:
> 
> Blunt, I don't mind.  But an explanation would be useful.

Well, just in order.

Quotas actually don't seem to be used very much.  Instead people Greenspun it by confining applications to distinct filesystems and some kind of volume manager.  Changing a quota now consists of adding "disks" (which are of course actually chunks of space carved out of some underlying array and probably don't correspond to real disk boundaries at all) to the volume manager, and then resizing the filesystem on the fly.  If you want to reduce the "quota" you're in for hours of I/O as the FS evacuates the disks, if you can do it at all.  One day they will discover NFS over IP/ethernet with quotas.

Privilege separation is more sorted out.  People (regulators, auditors, the organisation itself) are extremely interested in knowing who can see and do what.  Root access seems to be typically pretty sorted by now (no-one has it except under some kind of auditable breakglass process) and controlling per-user access is getting tied down where it hasn't been, usually by elaborate sudo rules for the various role users (unix admin, oracle admin, business users etc).  Most of this really needs MAC, but the practical problem seems to be that the rule-based things (like sudo) implementing the access controls become so complex people can't understand them (I think the sudoers file where I work is 10,000 lines).  I think more sophisicated privilege models (which all the flavours probably have now, but in incompatible ways) would probably make the complexity worse.

Sorry, this is off-topic, although in some ways it's relevant I suppose: using a system like Unix in an environment for which it really wasn't designed leads to insane complexity.

[TUHS] History of chown semantics

[John Cowan]

Tim Bradshaw scripsit:

> If you are a bank and would like to continue being a bank then all of this is false.  (Sorry to be so blunt).

Blunt, I don't mind.  But an explanation would be useful.

-- 
A witness cannot give evidence of his           John Cowan
age unless he can remember being born.          cowan at ccil.org
  --Judge Blagden                               http://www.ccil.org/~cowan

[TUHS] History of chown semantics

[Brian S Walden]

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

[TUHS] History of chown semantics

[Ed Carp]

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.  :)
 On Jan 9, 2014 6:58 AM, "Clem Cole" <clemc at ccc.com> wrote:

> Ron's right - it was PWB that started the file give away semantic not BSD
> or the Research kernels..  PWB gave way to PWB 2,0, then PWB 3.0 aka
>  System III  .    As for who's idea it was, you probably should ask some
> one like Mash.  I suspect there was some reason for it in the original
> tools --> a guess -.. maybe it some how it helped the IBM RJE stuff that
> PWB developed/supported - any one else remember?
>
> I agree with you, I always thought it was crazy and always seem to be
> caused me a number of issues with things like tape utilities.    Since the
> Masscomp kernel was a System III/BSD blend, and the Stellix kernel was
> System V3/BSD - we supported it and was were I first really had to deal
> with it.   I don't remember if we made the kernel behavior dependent on the
> universe setting - but I suspect not.
>
>
> Anyway, the idea of file give-away made it into the SVID as a result of
> being part of the PWB heritage. There was a definite argument in the POSIX
> meetings if it was good idea to allow it just because SVID allowed it.
>  Some of us thought it was a crazy concept (aka a bad idea).   But at the
> time, there was a large group that fought anything that was not SVID
> ("System V - consider it standard") - they just wanted to take SVID and
> bless it.
>
> I do not believe that Sun pick up the semantic until the Solaris project
> when the start to take SVR4 and fold Sun things into it.  I did not think
> BSD ever took it.   If it did it was post 4.3.
>
> I remember the argument int he early POSIX meetings, I've forgotten why
> some of backed down and let it stand.    Bostic or Quarterman might
> remember as I seem to think they were at that set of meetings also.
>
>
> Clem
>
>
> On Thu, Jan 9, 2014 at 7:46 AM, Ronald Natalie <ron at ronnatalie.com> wrote:
>
>> To my knowledge none of the "research" versions allowed chown() other
>> than for the superuser.
>>
>> The non-su behavior seems to have orginated in PWB UNIX.
>>
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140110/3560dc0f/attachment.html>

[TUHS] History of chown semantics

[Larry McVoy]

On Fri, Jan 10, 2014 at 10:16:06AM -0500, Clem Cole wrote:
> Surely there is no accounting for taste ;-)

Yeah, someone married me so I think that pretty much proves your point :)
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[TUHS] History of chown semantics

[Clem Cole]

On Thu, Jan 9, 2014 at 8:01 PM, Larry McVoy <lm at bitmover.com> wrote:

> On Thu, Jan 09, 2014 at 07:15:55PM -0500, Brian S Walden wrote:
> > 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


Amen.

Brian - thank you for explaining from where the feature came.  It makes
more sense to be that issue that cause it was clearly the small number of
UID the incorrect use of GIDs and groups.   A fix to UID was later
implemented in the other editions, and I expect if PWB had done it earlier
- dmr et al would have "bought back" that one also.

While I'm glad to hear the explanation.  I admit that do not buy the IBM
programmer stuff. I know for a fair  number of us, from friend wnj, the
late Ted Kowalski (aka frodo) to many of us others programmed on TSS, MTS
as well as other IBM systems before UNIX.   The concept of file give-away
still seems far fetched as an explanation of it helped the user base.

Greg's example if his wife were in his group and it was properly used, its
not an issue (all of my family are included in group "ccc" on our all
systems at home and I do exactly the same thing).    Brian said - "proper
use of group ids." -- I think its going to be hard to convince a number of
us that file give-away is a good idea when you have groups.  Frankly, I
think it violated Mash's own "small" change directive - as we have together
pointed out it has so many side effects. The times where it actually might
be helpful seems pretty small and all of those case so far that we can
think of there are better solutions already baked into UNIX.  The negatives
of a file give-away feature (at least to me and I suspect many if us who
find it distasteful) are so many.

All that said -- the mystery and original Tim question that started this
thread has been answered...  thank you all.

Source -- PWB (1.0)
Why - seems to be it solved an issue with how UID/GIDS were used in
practice in the PWB world.

IMO:  it's to bad it got baked in SVID and POSIX when we had other
solutions the problems that needed to be solved.  But clearly others such
as Brian and Greg like it.  Surely there is no accounting for taste ;-)

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140110/aaa12335/attachment.html>

[TUHS] History of chown semantics

[Ronald Natalie]

Boy, I'm amazed at the controversy here.   Yeah, I thought the feature was odd when it appeared, but it's not nearly as bizarre as the perils of allowing random users to mount disks (we hacked our mostly V6 kernel at JHU to disable setuid on mounted disks)  or the fact that non-privileged users could invoke setuid/setgid (managed to exploit a few bugs here in the day).

[TUHS] History of chown semantics

[scj]

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.


> 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.
>>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>

[TUHS] History of chown semantics

[Tim Bradshaw]

On 10 Jan 2014, at 04:28, Greg 'groggy' Lehey wrote:

> None of this contradicts the issues with allowing non-root chown, but
> it does show a valid reason to want to do so.

Another use which I am fairly sure I read about somewhere is student submissions of work. Scenario is: student writes program / essay / something, and at some point you want them to be able to submit it in such a way that they can no longer change it.  You can do that without SUID programs if you can give away files.

[TUHS] History of chown semantics

[Tim Bradshaw]

On 9 Jan 2014, at 19:13, John Cowan wrote:

> Quotas aren't very useful any more, what with most systems being either
> single-user clients or servers with no need for privilege separation
> other than root/non-root.  Unless you are using mandatory access
> control, which has never been a standard part of any Unix-like system, I
> see no reason to continue to forbid changes of ownership.

If you are a bank and would like to continue being a bank then all of this is false.  (Sorry to be so blunt).

[TUHS] History of chown semantics

[Greg 'groggy' Lehey]

On Thursday,  9 January 2014 at 17:03:44 -0500, Clem Cole wrote:
>
> 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.

A real-life modern example: my wife has a digital camera with a card
that her OS can't read.  So she gives it to me, I take out the card
and read it onto the disk for her, which she then accesses via NFS.
As a result the files belong to me, and to enable her write access, I
have to chmod the directory.  A chown would be more appropriate.

None of this contradicts the issues with allowing non-root chown, but
it does show a valid reason to want to do so.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140110/01f36f71/attachment.sig>

[TUHS] History of chown semantics

[Brian S Walden]

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

[TUHS] History of chown semantics

[Larry McVoy]

On Thu, Jan 09, 2014 at 07:15:55PM -0500, Brian S Walden wrote:
> 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.

[TUHS] History of chown semantics

[John Cowan]

Clem Cole scripsit:

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

All restrictions make things easier for admins: that alone is not a
justification for them.

-- 
John Cowan <cowan at ccil.org>             http://www.ccil.org/~cowan
The peculiar excellence of comedy is its excellent fooling, and Aristophanes's
claim to immortality is based upon one title only: he was a master maker
of comedy, he could fool excellently.  Here Gilbert stands side by side
with him.  He, too, could write the most admirable nonsense.  There has
never been better fooling than his, and a comparison with him carries
nothing derogatory to the great Athenian. --Edith Hamilton, The Greek Way

[TUHS] History of chown semantics

[Brian S Walden]

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 

[TUHS] History of chown semantics

[Cyrille Lefevre]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

Le 09/01/2014 11:59, Tim Bradshaw a écrit :
>
> 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.

hi,

forgot that HP-UX enable chown by default if /etc/privgroup doesn't 
exists..., but the following page document this well :

http://www.unixguide.net/hp/faq/5.1.1.shtml

Regards,

Cyrille Lefevre
-- 
mailto:Cyrille.Lefevre-lists at laposte.net

[TUHS] History of chown semantics

[Clem Cole]

On Thu, Jan 9, 2014 at 4:29 PM, Brian S Walden <tuhs at cuzuco.com> wrote:

> http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-2177.pdf


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140109/54ff88ef/attachment.html>

[TUHS] History of chown semantics

[Doug McIlroy]

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.

[TUHS] History of chown semantics

[Brian S Walden]

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

[TUHS] History of chown semantics

[Warner Losh]

On Jan 9, 2014, at 1:19 PM, Tim Newsham wrote:

> On Thu, Jan 9, 2014 at 9:13 AM, John Cowan <cowan at mercury.ccil.org> wrote:
>> Quotas aren't very useful any more, what with most systems being either
>> single-user clients or servers with no need for privilege separation
>> other than root/non-root.  Unless you are using mandatory access
>> control, which has never been a standard part of any Unix-like system, I
>> see no reason to continue to forbid changes of ownership.
> 
> I think such a drastic change in semantics is bound to violate
> some security assumption of some software.
> 
> For example, some program might have you create a file
> and use your ownership of that file as proof of your
> authorization.

I always had been told it was so that you could chown the tape drive back to root when you were done with it... Or was that the weird, fancy type-setter... But this is far from a first-hand account.

Warner

[TUHS] History of chown semantics

[Tim Newsham]

On Thu, Jan 9, 2014 at 9:13 AM, John Cowan <cowan at mercury.ccil.org> wrote:
> Quotas aren't very useful any more, what with most systems being either
> single-user clients or servers with no need for privilege separation
> other than root/non-root.  Unless you are using mandatory access
> control, which has never been a standard part of any Unix-like system, I
> see no reason to continue to forbid changes of ownership.

I think such a drastic change in semantics is bound to violate
some security assumption of some software.

For example, some program might have you create a file
and use your ownership of that file as proof of your
authorization.

-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

[TUHS] History of chown semantics

[Clem Cole]

On Thu, Jan 9, 2014 at 2:48 PM, Armando Stettner <aps at ieee.org> wrote:

>  If it was allowed to change owners, surely it wouldn't allow one to chown
> to root.  (Sorry about calling you Surely.)


Yep - you could -- see the code I sent,   The only thing they did was mask
the *ID bits,'  Surely...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140109/e2506afd/attachment.html>

[TUHS] History of chown semantics

[Clem Cole]

On Thu, Jan 9, 2014 at 2:23 PM, Brian S Walden <tuhs at cuzuco.com> wrote:

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



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140109/6523915b/attachment.html>

[TUHS] History of chown semantics

[Armando Stettner]

Dos this mean that on some implementations of UNIX, that the chown(2) was usable by non-root processes???  Maybe I misremembered but I thought that that would fail - even the chown(1) would fail - if the invoking process (or shell in the case of chown(1)) was not superuser.  If it was allowed to change owners, surely it wouldn't allow one to chown to root.  (Sorry about calling you Surely.)

  aps.


Begin forwarded message:

> From: Clem Cole <clemc at ccc.com>
> Subject: Re: [TUHS] History of chown semantics
> Date: January 9, 2014 10:48:04 AM PST
> To: Ron Natalie <ron at ronnatalie.com>
> Cc: TUHS main list <tuhs at minnie.tuhs.org>
> 
> Right ...  tools like tar(1) called the system call directly,
> Which is why the restriction/check in the research family was done in the OS.
> The PWB kernel did not make the check - although V6 did:
> 
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys4.c
> chown()
> {
> 	register *ip;
> 
> 	if (
> !suser() 
> || (ip = owner()) == NULL)
> 		return;
> 	ip->i_uid = u.u_arg[1].lobyte;
> 	ip->i_gid = u.u_arg[1].hibyte;
> 	ip->i_flag =| IUPD;
> 	iput(ip);
> }
> 
> 
> 
> Where as: PWB 1.0:
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys4.c
> chown()
> {
> 	register *ip;
> 
> 	if ((ip = owner()) == NULL)
> 		return;
> 	ip->i_uid = u.u_arg[1].lobyte;
> 	ip->i_gid = u.u_arg[1].hibyte;
> 	if(u.u_uid != 0)
> 		ip->i_mode =& ~(ISUID|ISGID);
> 	ip->i_flag =| IUPD;
> 	iput(ip);
> }
> 
> 
> Clem
> 
> 
> On Thu, Jan 9, 2014 at 1:31 PM, Ron Natalie <ron at ronnatalie.com> wrote:
> There's no real point in restricting the chown program if the system call
> remains executable by non-root.
> 
> -----Original Message-----
> From: tuhs-bounces at minnie.tuhs.org [mailto:tuhs-bounces at minnie.tuhs.org] On
> Behalf Of Dario Niedermann
> Sent: Thursday, January 9, 2014 1:18 PM
> To: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] History of chown semantics
> 
> Il 09/01/2014 alle 15:56, Clem Cole ha scritto:
> 
> > I agree with you, I always thought it was crazy [...]
> 
> Maybe I'm missing something, but it seems easy enough to make the `chown'
> program only executable by root.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] History of chown semantics

[Brian S Walden]

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

[TUHS] History of chown semantics

[John Cowan]

Jeremy C. Reed scripsit:

> A few years ago, Thompson had told me that while at Berkeley (on a  
> sabbatical), he did a modification at Berkeley to put in disk space 
> quotas to prevent runaways.                                         

This is apparently not the same as Robert Elz's disc [sic] quotas, which
were first released with 4.2BSD.  That was the first version to cash the
cheque supplied by all Research versions until 8th Edition:

> "Only the super-user is allowed to change the owner of a file, in
> order to simplify as yet unimplemented accounting procedures."

Since there were never any such procedures in the line leading to System
V, there was no longer any reason to restrict giving away files.

Quotas aren't very useful any more, what with most systems being either
single-user clients or servers with no need for privilege separation
other than root/non-root.  Unless you are using mandatory access
control, which has never been a standard part of any Unix-like system, I
see no reason to continue to forbid changes of ownership.

> http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/chownall.c has:
> if (chgusr && !chggrp && source.uid == 0)
> 	panic("owner of \"%s\" is uid 0 in his group !?!", spth);
> else if (!chgusr && chggrp && source.uid != 0)
> 	panic("owner of \"%s\" is not uid 0 of his group !?!", spth);
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/man6/chownall.6
> also mentions the "user number 0 in his group." 

Looking at
<http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/man6/chownall.6>
suggests that in the base system underlying 1BSD, you were only the
superuser if you had a uid of 0 and a gid of 0.  I suspect this was a
kernel patch.

-- 
First known example of political correctness:   John Cowan
After Nurhachi had united all the other         http://www.ccil.org/~cowan
Jurchen tribes under the leadership of the      cowan at ccil.org
Manchus, his successor Abahai (1592-1643)
issued an order that the name Jurchen should       --S. Robert Ramsey,
be banned, and from then on, they were all           The Languages of China
to be called Manchus.

[TUHS] History of chown semantics

[Warner Losh]

On Jan 9, 2014, at 11:18 AM, Dario Niedermann wrote:

> Il 09/01/2014 alle 15:56, Clem Cole ha scritto:
> 
>> I agree with you, I always thought it was crazy [...]
> 
> Maybe I'm missing something, but it seems easy enough to make the
> `chown' program only executable by root.

chown(2) has to do the enforcement. chown(1) or the filesystem doing it doesn't help so much.

Warner

[TUHS] History of chown semantics

[Clem Cole]

Right ...  tools like tar(1) called the system call directly,
Which is why the restriction/check in the research family was done in the
OS.
The PWB kernel did not make the check - although V6 did:

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys4.c

chown()
{
	register *ip;

	if (!suser() || (ip = owner()) == NULL)
		return;
	ip->i_uid = u.u_arg[1].lobyte;
	ip->i_gid = u.u_arg[1].hibyte;
	ip->i_flag =| IUPD;
	iput(ip);
}



Where as: PWB 1.0:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys4.c

chown()
{
	register *ip;

	if ((ip = owner()) == NULL)
		return;
	ip->i_uid = u.u_arg[1].lobyte;
	ip->i_gid = u.u_arg[1].hibyte;
	if(u.u_uid != 0)
		ip->i_mode =& ~(ISUID|ISGID);
	ip->i_flag =| IUPD;
	iput(ip);
}


Clem


On Thu, Jan 9, 2014 at 1:31 PM, Ron Natalie <ron at ronnatalie.com> wrote:

> There's no real point in restricting the chown program if the system call
> remains executable by non-root.
>
> -----Original Message-----
> From: tuhs-bounces at minnie.tuhs.org [mailto:tuhs-bounces at minnie.tuhs.org]
> On
> Behalf Of Dario Niedermann
> Sent: Thursday, January 9, 2014 1:18 PM
> To: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] History of chown semantics
>
> Il 09/01/2014 alle 15:56, Clem Cole ha scritto:
>
> > I agree with you, I always thought it was crazy [...]
>
> Maybe I'm missing something, but it seems easy enough to make the `chown'
> program only executable by root.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140109/1a469662/attachment.html>

[TUHS] History of chown semantics

[Clem Cole]

Ed, Bob Kridle or Asa Romberger would be good people to ask.   I've
forgotten about the Fascist FS until you just mentioned it,   I seem to
remember there was some work done on the Cory Hall machines to support
using UNIX as a platform for CS classes and that FS was part of it.   I've
completely forgotten what it all was other than the Pascal subsystem,   My
memory is that not all of it migrated from the V6 based BSD system (aka
1BSD) to the later V7 based systems which the Vax (3/4BSD )and later
(2.XBSD) work was done.

Kirk's SCCS files might have some of that in it, but I think he only
captured from the VAX work onward - aka CSRG.


On Thu, Jan 9, 2014 at 12:01 PM, Jeremy C. Reed <reed at reedmedia.net> wrote:

> I am also interested in this (and had researched it a little for my book
> about history of Berkeley Unix).
>
> A few years ago, Thompson had told me that while at Berkeley (on a
> sabbatical), he did a modification at Berkeley to put in disk space
> quotas to prevent runaways. (This "Berkeley" modification is also
> mentioned in the pascal docs, see
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/doc/pascal/puman3.n )
> I thought it was as a side-effect of this that users couldn't chown
> files to others (since can't cause quota problems for others). But now I
> see that already existed:
>
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/chown.8
> from 1975 mentions "Only the super-user is allowed to change the owner
> of a file, in order to simplify as yet unimplemented accounting
> procedures."
>
> But it appears that some Berkeley systems did have a concept of some
> non-root users chowning files. Apparently there was a Berkeley Fascist
> File System where only group masters were able to chown files owned by
> members of a group. I also read there was a concept of "class users"
> (uid < 0) who could not access others files regardless of open
> permissions. For references see
> http://www.dnull.com/bsd/oldnews/bsdnew20597.html
>
> https://groups.google.com/forum/#!original/net.unix-wizards/RasSNg_DNHM/2Ty6wyObAFQJ
>
> https://groups.google.com/forum/#!original/comp.unix.questions/I1nkZGl8Hl0/PYkaPZtvaeEJ
> (Ed Gould from Berkeley also mentioned it to me.)
>
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/upgrade/src/last.c
> mentions "non-class users".
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/man6/dates.6 manual
> mentions "class master accounts".
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/man6/whoison.6 appears
> to define "class" and winfo database (which is not in 2BSD).
>
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/chownall.c
> has:
> if (chgusr && !chggrp && source.uid == 0)
>         panic("owner of \"%s\" is uid 0 in his group !?!", spth);
> else if (!chgusr && chggrp && source.uid != 0)
>         panic("owner of \"%s\" is not uid 0 of his group !?!", spth);
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/man6/chownall.6
> also mentions the "user number 0 in his group."
>
> I am not sure what this concept of uid 0 "of a group" means. The way it
> is all worded I don't think it is superuser uid 0. I think "group
> master" is the same as "class master" and same as "uid 0 of a group".
> Can anyone explain this?  (I can't find this concept in 2BSD nor 3BSD.)
>
> Maybe this too much of a tangent, but seems to be about an old example
> of users giving away files.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140109/0bd472ec/attachment.html>

[TUHS] History of chown semantics

[Tim Bradshaw]

On 9 Jan 2014, at 18:18, Dario Niedermann wrote:
> 
> Maybe I'm missing something, but it seems easy enough to make the
> `chown' program only executable by root.

It's not the program, it's the system call.

[TUHS] History of chown semantics

[Ron Natalie]

There's no real point in restricting the chown program if the system call
remains executable by non-root.

-----Original Message-----
From: tuhs-bounces@minnie.tuhs.org [mailto:tuhs-bounces@minnie.tuhs.org] On
Behalf Of Dario Niedermann
Sent: Thursday, January 9, 2014 1:18 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] History of chown semantics

Il 09/01/2014 alle 15:56, Clem Cole ha scritto:

> I agree with you, I always thought it was crazy [...]

Maybe I'm missing something, but it seems easy enough to make the `chown'
program only executable by root.
_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] History of chown semantics

[Dario Niedermann]

Il 09/01/2014 alle 15:56, Clem Cole ha scritto:

> I agree with you, I always thought it was crazy [...]

Maybe I'm missing something, but it seems easy enough to make the
`chown' program only executable by root.

[TUHS] History of chown semantics

[Jeremy C. Reed]

I am also interested in this (and had researched it a little for my book 
about history of Berkeley Unix).

A few years ago, Thompson had told me that while at Berkeley (on a 
sabbatical), he did a modification at Berkeley to put in disk space 
quotas to prevent runaways. (This "Berkeley" modification is also 
mentioned in the pascal docs, see 
http://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/doc/pascal/puman3.n ) 
I thought it was as a side-effect of this that users couldn't chown 
files to others (since can't cause quota problems for others). But now I 
see that already existed:

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/chown.8 
from 1975 mentions "Only the super-user is allowed to change the owner 
of a file, in order to simplify as yet unimplemented accounting 
procedures."

But it appears that some Berkeley systems did have a concept of some 
non-root users chowning files. Apparently there was a Berkeley Fascist 
File System where only group masters were able to chown files owned by 
members of a group. I also read there was a concept of "class users" 
(uid < 0) who could not access others files regardless of open 
permissions. For references see
http://www.dnull.com/bsd/oldnews/bsdnew20597.html
https://groups.google.com/forum/#!original/net.unix-wizards/RasSNg_DNHM/2Ty6wyObAFQJ
https://groups.google.com/forum/#!original/comp.unix.questions/I1nkZGl8Hl0/PYkaPZtvaeEJ
(Ed Gould from Berkeley also mentioned it to me.)

http://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/upgrade/src/last.c 
mentions "non-class users".
http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/man6/dates.6 manual 
mentions "class master accounts".
http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/man6/whoison.6 appears 
to define "class" and winfo database (which is not in 2BSD).

http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/chownall.c
has:
if (chgusr && !chggrp && source.uid == 0)
	panic("owner of \"%s\" is uid 0 in his group !?!", spth);
else if (!chgusr && chggrp && source.uid != 0)
	panic("owner of \"%s\" is not uid 0 of his group !?!", spth);
http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/man6/chownall.6
also mentions the "user number 0 in his group." 

I am not sure what this concept of uid 0 "of a group" means. The way it 
is all worded I don't think it is superuser uid 0. I think "group 
master" is the same as "class master" and same as "uid 0 of a group".  
Can anyone explain this?  (I can't find this concept in 2BSD nor 3BSD.)

Maybe this too much of a tangent, but seems to be about an old example 
of users giving away files.

[TUHS] History of chown semantics

[Clem Cole]

On Thu, Jan 9, 2014 at 10:17 AM, Tim Bradshaw <tfb at tfeb.org> wrote:

> so probably they did not do this either: must have been some other system
> I used (Masscomps?)


I did something about it on RTU - I've just forgotten what.  Since tar came
from research which did have that kernel behavior, I'm guessing we modified
tar when in read (input) mode  to not call chown unless it was run as root.

To fix  the other issue with importing a tape that could be an issue, we
(mil did the code it I remember correctly) also added a way to strip the
leading slash from tar images on input so if some one wrote a tape with
full paths you could import it path relative - which the research/BSD
versions did not do - which until pax came along and later gnutar was not
easy to do.


Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140109/8ea0544e/attachment.html>

[TUHS] History of chown semantics

[Tim Bradshaw]

On 9 Jan 2014, at 14:56, Clem Cole wrote:

> I agree with you, I always thought it was crazy and always seem to be caused me a number of issues with things like tape utilities. 

That's how I found it.  tar xfp will almost never work as an ordinary user on a system like this.

I don't think it is in Solaris: for my sins (which must be many, clearly) I've spent a lot of time running Solaris systems and I can't remember them allowing this.  My memory of SunOS (as in 4 or earlier) systems is too vague to be sure though I am sure tar xfp worked, so probably they did not do this either: must have been some other system I used (Masscomps?)

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140109/b11bd379/attachment.html>

[TUHS] History of chown semantics

[Clem Cole]

Ron's right - it was PWB that started the file give away semantic not BSD
or the Research kernels..  PWB gave way to PWB 2,0, then PWB 3.0 aka
 System III  .    As for who's idea it was, you probably should ask some
one like Mash.  I suspect there was some reason for it in the original
tools --> a guess -.. maybe it some how it helped the IBM RJE stuff that
PWB developed/supported - any one else remember?

I agree with you, I always thought it was crazy and always seem to be
caused me a number of issues with things like tape utilities.    Since the
Masscomp kernel was a System III/BSD blend, and the Stellix kernel was
System V3/BSD - we supported it and was were I first really had to deal
with it.   I don't remember if we made the kernel behavior dependent on the
universe setting - but I suspect not.


Anyway, the idea of file give-away made it into the SVID as a result of
being part of the PWB heritage. There was a definite argument in the POSIX
meetings if it was good idea to allow it just because SVID allowed it.
 Some of us thought it was a crazy concept (aka a bad idea).   But at the
time, there was a large group that fought anything that was not SVID
("System V - consider it standard") - they just wanted to take SVID and
bless it.

I do not believe that Sun pick up the semantic until the Solaris project
when the start to take SVR4 and fold Sun things into it.  I did not think
BSD ever took it.   If it did it was post 4.3.

I remember the argument int he early POSIX meetings, I've forgotten why
some of backed down and let it stand.    Bostic or Quarterman might
remember as I seem to think they were at that set of meetings also.


Clem


On Thu, Jan 9, 2014 at 7:46 AM, Ronald Natalie <ron at ronnatalie.com> wrote:

> To my knowledge none of the "research" versions allowed chown() other than
> for the superuser.
>
> The non-su behavior seems to have orginated in PWB UNIX.
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140109/503e52ce/attachment.html>

[TUHS] History of chown semantics

[Ronald Natalie]

To my knowledge none of the "research" versions allowed chown() other than for the superuser.

The non-su behavior seems to have orginated in PWB UNIX.

[TUHS] History of chown semantics

[Tim Bradshaw]

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