From ron at ronnatalie.com Thu Jan 9 05:28:55 2014 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Wed, 08 Jan 2014 14:28:55 -0500 Subject: [TUHS] Cleaning out the basement Message-ID: OK, let me try this one more time with links to get around the restrictions on the message size. I was cleaning out my basement and I found a box of stuff from my office at BRL (where I left in 1987). Most of it was buttons I'd picked up at trade shows and SF cons (I had a fabric partition next to my desk that I had them all stuck to. Of course in the box (among a couple of later editions) was Armando's original UNIX license (note no reference to DEC): Also in the box were some buttons from various UNIX conferences. I particularly remember the Sex, Drugs, and Unix one. Some of you will also remember the year I was giving out the No Ada shirts. There's a picture of dmr wearing one floating around somewhere. Sun was giving out these one year: Peter Langston thought this was a little conceited on Bill Joy's part, so the next show he arrived with buttons to hand out that said things like "The psl of UNIX" and "The dmr of UNIX". I had a "The ron of UNIX" somewhere but I couldn't find it in the box. Finally there was this wooden nickle courtesy of Bill Yost... -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 9 06:09:56 2014 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Jan 2014 15:09:56 -0500 Subject: [TUHS] Cleaning out the basement In-Reply-To: References: Message-ID: I love to tell a story about the Sex, Drugs and UNIX button. I'm in my disheveled tee-shirt/jeans and wearing one of those button in the elevator in hotel in Toronto talking with a couple of my co-workers: Al Nugent and Mike Krueger; when your basic American midwestern family gets on. Remember this is right when AIDS epidemic is just making into in the press. The mother sees the button and asks, "What a UNIX?" Krueger brightly replies: "It like AIDS, only worse." She immediately grabs her kids and cowers in the corner of the elevator. I'm shaking my head in disgust and turned to Krueger and called him the "#$%^& Prince of Darkness." By this point, Nugent is laughing riotously. FYI the name stuck. Even today when I see folks from Masscomp and folks ask what happened to person X or Y, - "The #$%^& Prince of Darkness" is still referred too by that term of endearment. Clem On Wed, Jan 8, 2014 at 2:28 PM, wrote: > OK, let me try this one more time with links to get around the restrictions on the message size. > > I was cleaning out my basement and I found a box of stuff from my office at BRL (where I left in 1987). > Most of it was buttons I'd picked up at trade shows and SF cons (I had a fabric partition next to my desk that I had them all stuck to. > > Of course in the box (among a couple of later editions) was Armando's original UNIX license (note no reference to DEC): > > > Also in the box were some buttons from various UNIX conferences. I > particularly remember the Sex, Drugs, and Unix one. Some of you will > also remember the year I was giving out the No Ada shirts. There's a > picture of dmr wearing one floating around somewhere. > > > > Sun was giving out these one year: > > Peter Langston thought this was a little conceited on Bill Joy's part, so > the next show he arrived with buttons to hand out that said things like > "The psl of UNIX" and "The dmr of UNIX". I had a "The ron of UNIX" > somewhere but I couldn't find it in the box. > > Finally there was this wooden nickle courtesy of Bill Yost... > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfb at tfeb.org Thu Jan 9 20:59:43 2014 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 9 Jan 2014 10:59:43 +0000 Subject: [TUHS] History of chown semantics Message-ID: 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 From ron at ronnatalie.com Thu Jan 9 22:46:43 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 9 Jan 2014 07:46:43 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: 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. From clemc at ccc.com Fri Jan 10 00:56:18 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2014 09:56:18 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: 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 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: From tfb at tfeb.org Fri Jan 10 01:17:26 2014 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 9 Jan 2014 15:17:26 +0000 Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: 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: From clemc at ccc.com Fri Jan 10 01:31:26 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2014 10:31:26 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: On Thu, Jan 9, 2014 at 10:17 AM, Tim Bradshaw 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: From reed at reedmedia.net Fri Jan 10 03:01:01 2014 From: reed at reedmedia.net (Jeremy C. Reed) Date: Thu, 9 Jan 2014 11:01:01 -0600 (CST) Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: 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. From dnied at tiscali.it Fri Jan 10 04:18:24 2014 From: dnied at tiscali.it (Dario Niedermann) Date: Thu, 9 Jan 2014 19:18:24 +0100 Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: <20140109181824.GA10087@dnied%tiscali.it> 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. From ron at ronnatalie.com Fri Jan 10 04:31:25 2014 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 9 Jan 2014 13:31:25 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <20140109181824.GA10087@dnied%tiscali.it> References: <20140109181824.GA10087@dnied%tiscali.it> Message-ID: <013901cf0d69$01e11890$05a349b0$@ronnatalie.com> 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 From tfb at tfeb.org Fri Jan 10 04:37:12 2014 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 9 Jan 2014 18:37:12 +0000 Subject: [TUHS] History of chown semantics In-Reply-To: <20140109181824.GA10087@dnied%tiscali.it> References: <20140109181824.GA10087@dnied%tiscali.it> Message-ID: <380B2525-0ED8-4771-B4F0-81B4A053F381@tfeb.org> 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. From clemc at ccc.com Fri Jan 10 04:40:59 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2014 13:40:59 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: 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 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: From clemc at ccc.com Fri Jan 10 04:48:04 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2014 13:48:04 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <013901cf0d69$01e11890$05a349b0$@ronnatalie.com> References: <20140109181824.GA10087@dnied%tiscali.it> <013901cf0d69$01e11890$05a349b0$@ronnatalie.com> Message-ID: 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 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: From imp at bsdimp.com Fri Jan 10 04:55:39 2014 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Jan 2014 11:55:39 -0700 Subject: [TUHS] History of chown semantics In-Reply-To: <20140109181824.GA10087@dnied%tiscali.it> References: <20140109181824.GA10087@dnied%tiscali.it> Message-ID: <0328CF07-EDE0-4813-8B24-A3B417044599@bsdimp.com> 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 From tuhs at cuzuco.com Fri Jan 10 05:23:31 2014 From: tuhs at cuzuco.com (Brian S Walden) Date: Thu, 9 Jan 2014 14:23:31 -0500 (EST) Subject: [TUHS] History of chown semantics Message-ID: <201401091923.s09JNVRw003234@cuzuco.com> 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 > > 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 From cowan at mercury.ccil.org Fri Jan 10 05:13:37 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Thu, 9 Jan 2014 14:13:37 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: <20140109191336.GD24304@mercury.ccil.org> 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 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. From aps at ieee.org Fri Jan 10 05:48:30 2014 From: aps at ieee.org (Armando Stettner) Date: Thu, 9 Jan 2014 11:48:30 -0800 Subject: [TUHS] History of chown semantics In-Reply-To: References: <20140109181824.GA10087@dnied%tiscali.it> <013901cf0d69$01e11890$05a349b0$@ronnatalie.com> Message-ID: 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 > Subject: Re: [TUHS] History of chown semantics > Date: January 9, 2014 10:48:04 AM PST > To: Ron Natalie > Cc: TUHS main list > > 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 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 From clemc at ccc.com Fri Jan 10 05:51:12 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2014 14:51:12 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <201401091923.s09JNVRw003234@cuzuco.com> References: <201401091923.s09JNVRw003234@cuzuco.com> Message-ID: On Thu, Jan 9, 2014 at 2:23 PM, Brian S Walden 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: From clemc at ccc.com Fri Jan 10 05:52:36 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2014 14:52:36 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: References: <20140109181824.GA10087@dnied%tiscali.it> <013901cf0d69$01e11890$05a349b0$@ronnatalie.com> Message-ID: On Thu, Jan 9, 2014 at 2:48 PM, Armando Stettner 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: From tim.newsham at gmail.com Fri Jan 10 06:19:24 2014 From: tim.newsham at gmail.com (Tim Newsham) Date: Thu, 9 Jan 2014 10:19:24 -1000 Subject: [TUHS] History of chown semantics In-Reply-To: <20140109191336.GD24304@mercury.ccil.org> References: <20140109191336.GD24304@mercury.ccil.org> Message-ID: On Thu, Jan 9, 2014 at 9:13 AM, 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. 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 From imp at bsdimp.com Fri Jan 10 06:43:04 2014 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Jan 2014 13:43:04 -0700 Subject: [TUHS] History of chown semantics In-Reply-To: References: <20140109191336.GD24304@mercury.ccil.org> Message-ID: <4B63B254-11FA-401C-81EE-7B4A8B97EDF6@bsdimp.com> On Jan 9, 2014, at 1:19 PM, Tim Newsham wrote: > On Thu, Jan 9, 2014 at 9:13 AM, 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. > > 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 From tuhs at cuzuco.com Fri Jan 10 07:29:11 2014 From: tuhs at cuzuco.com (Brian S Walden) Date: Thu, 9 Jan 2014 16:29:11 -0500 (EST) Subject: [TUHS] History of chown semantics Message-ID: <201401092129.s09LTBBg001272@cuzuco.com> 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 > > 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 From clemc at ccc.com Fri Jan 10 08:03:44 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2014 17:03:44 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <201401092129.s09LTBBg001272@cuzuco.com> References: <201401092129.s09LTBBg001272@cuzuco.com> Message-ID: On Thu, Jan 9, 2014 at 4:29 PM, Brian S Walden 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: From cyrille.lefevre-lists at laposte.net Fri Jan 10 08:57:49 2014 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Thu, 09 Jan 2014 23:57:49 +0100 Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: <52CF296D.1040503@laposte.net> 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 From tuhs at cuzuco.com Fri Jan 10 10:15:55 2014 From: tuhs at cuzuco.com (Brian S Walden) Date: Thu, 9 Jan 2014 19:15:55 -0500 (EST) Subject: [TUHS] History of chown semantics Message-ID: <201401100015.s0A0FttO021699@cuzuco.com> 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 > > 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 From cowan at mercury.ccil.org Fri Jan 10 10:59:04 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Thu, 9 Jan 2014 19:59:04 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: References: <201401092129.s09LTBBg001272@cuzuco.com> Message-ID: <20140110005904.GE24304@mercury.ccil.org> 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 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 From lm at bitmover.com Fri Jan 10 11:01:37 2014 From: lm at bitmover.com (Larry McVoy) Date: Thu, 9 Jan 2014 17:01:37 -0800 Subject: [TUHS] History of chown semantics In-Reply-To: <201401100015.s0A0FttO021699@cuzuco.com> References: <201401100015.s0A0FttO021699@cuzuco.com> Message-ID: <20140110010137.GN13343@bitmover.com> 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. From tuhs at cuzuco.com Fri Jan 10 11:41:38 2014 From: tuhs at cuzuco.com (Brian S Walden) Date: Thu, 9 Jan 2014 20:41:38 -0500 (EST) Subject: [TUHS] History of chown semantics Message-ID: <201401100141.s0A1fcTl029059@cuzuco.com> 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 > > > 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. > From grog at lemis.com Fri Jan 10 14:28:59 2014 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 10 Jan 2014 15:28:59 +1100 Subject: [TUHS] History of chown semantics In-Reply-To: References: <201401092129.s09LTBBg001272@cuzuco.com> Message-ID: <20140110042859.GB66543@eureka.lemis.com> 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: From tfb at tfeb.org Fri Jan 10 20:09:40 2014 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 10 Jan 2014 10:09:40 +0000 Subject: [TUHS] History of chown semantics In-Reply-To: <20140109191336.GD24304@mercury.ccil.org> References: <20140109191336.GD24304@mercury.ccil.org> Message-ID: <5128EE1B-28A2-4D5E-AE32-BEC6652DF1A1@tfeb.org> 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). From tfb at tfeb.org Fri Jan 10 20:15:40 2014 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 10 Jan 2014 10:15:40 +0000 Subject: [TUHS] History of chown semantics In-Reply-To: <20140110042859.GB66543@eureka.lemis.com> References: <201401092129.s09LTBBg001272@cuzuco.com> <20140110042859.GB66543@eureka.lemis.com> Message-ID: <29E9D88D-6AE9-4BCD-A986-65D516609A2F@tfeb.org> 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. From scj at yaccman.com Fri Jan 10 23:17:44 2014 From: scj at yaccman.com (scj at yaccman.com) Date: Fri, 10 Jan 2014 05:17:44 -0800 Subject: [TUHS] History of chown semantics In-Reply-To: <201401100141.s0A1fcTl029059@cuzuco.com> References: <201401100141.s0A1fcTl029059@cuzuco.com> Message-ID: 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 >> >> > 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 > From ron at ronnatalie.com Sat Jan 11 00:03:55 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 10 Jan 2014 09:03:55 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: References: <201401100141.s0A1fcTl029059@cuzuco.com> Message-ID: <3B5A98B1-5510-47CB-97A7-BC1C96EB7E2F@ronnatalie.com> 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). From tuhs at cuzuco.com Sat Jan 11 00:55:18 2014 From: tuhs at cuzuco.com (Brian S Walden) Date: Fri, 10 Jan 2014 09:55:18 -0500 (EST) Subject: [TUHS] History of chown semantics Message-ID: <201401101455.s0AEtIjY019641@cuzuco.com> 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: > > 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. > From lm at bitmover.com Sat Jan 11 01:21:20 2014 From: lm at bitmover.com (Larry McVoy) Date: Fri, 10 Jan 2014 07:21:20 -0800 Subject: [TUHS] History of chown semantics In-Reply-To: References: <201401100015.s0A0FttO021699@cuzuco.com> <20140110010137.GN13343@bitmover.com> Message-ID: <20140110152120.GT13343@bitmover.com> 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 From clemc at ccc.com Sat Jan 11 01:16:06 2014 From: clemc at ccc.com (Clem Cole) Date: Fri, 10 Jan 2014 10:16:06 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <20140110010137.GN13343@bitmover.com> References: <201401100015.s0A0FttO021699@cuzuco.com> <20140110010137.GN13343@bitmover.com> Message-ID: On Thu, Jan 9, 2014 at 8:01 PM, Larry McVoy 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: From erc at pobox.com Sat Jan 11 02:20:07 2014 From: erc at pobox.com (Ed Carp) Date: Fri, 10 Jan 2014 08:20:07 -0800 Subject: [TUHS] History of chown semantics In-Reply-To: References: Message-ID: 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" 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 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: From ron at ronnatalie.com Sat Jan 11 03:05:39 2014 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 10 Jan 2014 12:05:39 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <201401101455.s0AEtIjY019641@cuzuco.com> References: <201401101455.s0AEtIjY019641@cuzuco.com> Message-ID: <001b01cf0e26$30d252f0$9276f8d0$@ronnatalie.com> 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. From tuhs at cuzuco.com Sat Jan 11 03:08:51 2014 From: tuhs at cuzuco.com (Brian S Walden) Date: Fri, 10 Jan 2014 12:08:51 -0500 (EST) Subject: [TUHS] History of chown semantics Message-ID: <201401101708.s0AH8pNv015623@cuzuco.com> 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 > > 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. :) From cowan at mercury.ccil.org Sat Jan 11 03:18:19 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Fri, 10 Jan 2014 12:18:19 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <5128EE1B-28A2-4D5E-AE32-BEC6652DF1A1@tfeb.org> References: <20140109191336.GD24304@mercury.ccil.org> <5128EE1B-28A2-4D5E-AE32-BEC6652DF1A1@tfeb.org> Message-ID: <20140110171819.GA14513@mercury.ccil.org> 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 From tfb at tfeb.org Mon Jan 13 07:19:14 2014 From: tfb at tfeb.org (Tim Bradshaw) Date: Sun, 12 Jan 2014 21:19:14 +0000 Subject: [TUHS] History of chown semantics In-Reply-To: <20140110171819.GA14513@mercury.ccil.org> References: <20140109191336.GD24304@mercury.ccil.org> <5128EE1B-28A2-4D5E-AE32-BEC6652DF1A1@tfeb.org> <20140110171819.GA14513@mercury.ccil.org> Message-ID: <8F58DE51-60E5-4E41-AAEF-78CAC3C08DBC@tfeb.org> 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. From cowan at mercury.ccil.org Mon Jan 13 17:05:43 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 13 Jan 2014 02:05:43 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <8F58DE51-60E5-4E41-AAEF-78CAC3C08DBC@tfeb.org> References: <20140109191336.GD24304@mercury.ccil.org> <5128EE1B-28A2-4D5E-AE32-BEC6652DF1A1@tfeb.org> <20140110171819.GA14513@mercury.ccil.org> <8F58DE51-60E5-4E41-AAEF-78CAC3C08DBC@tfeb.org> Message-ID: <20140113070543.GC22593@mercury.ccil.org> 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) From tfb at tfeb.org Mon Jan 13 20:37:25 2014 From: tfb at tfeb.org (Tim Bradshaw) Date: Mon, 13 Jan 2014 10:37:25 +0000 Subject: [TUHS] History of chown semantics In-Reply-To: <20140113070543.GC22593@mercury.ccil.org> References: <20140109191336.GD24304@mercury.ccil.org> <5128EE1B-28A2-4D5E-AE32-BEC6652DF1A1@tfeb.org> <20140110171819.GA14513@mercury.ccil.org> <8F58DE51-60E5-4E41-AAEF-78CAC3C08DBC@tfeb.org> <20140113070543.GC22593@mercury.ccil.org> Message-ID: <9D0D12F6-B198-4793-8501-E366FC7E5CB1@tfeb.org> 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. From cowan at mercury.ccil.org Tue Jan 14 02:15:06 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 13 Jan 2014 11:15:06 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <9D0D12F6-B198-4793-8501-E366FC7E5CB1@tfeb.org> References: <20140109191336.GD24304@mercury.ccil.org> <5128EE1B-28A2-4D5E-AE32-BEC6652DF1A1@tfeb.org> <20140110171819.GA14513@mercury.ccil.org> <8F58DE51-60E5-4E41-AAEF-78CAC3C08DBC@tfeb.org> <20140113070543.GC22593@mercury.ccil.org> <9D0D12F6-B198-4793-8501-E366FC7E5CB1@tfeb.org> Message-ID: <20140113161506.GA31756@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 From szigiszabolcs at gmail.com Tue Jan 14 02:53:03 2014 From: szigiszabolcs at gmail.com (SZIGETI Szabolcs) Date: Mon, 13 Jan 2014 17:53:03 +0100 Subject: [TUHS] History of chown semantics In-Reply-To: <20140113161506.GA31756@mercury.ccil.org> References: <20140109191336.GD24304@mercury.ccil.org> <5128EE1B-28A2-4D5E-AE32-BEC6652DF1A1@tfeb.org> <20140110171819.GA14513@mercury.ccil.org> <8F58DE51-60E5-4E41-AAEF-78CAC3C08DBC@tfeb.org> <20140113070543.GC22593@mercury.ccil.org> <9D0D12F6-B198-4793-8501-E366FC7E5CB1@tfeb.org> <20140113161506.GA31756@mercury.ccil.org> Message-ID: 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 > 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: From cowan at mercury.ccil.org Tue Jan 14 04:16:35 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 13 Jan 2014 13:16:35 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: References: <20140109191336.GD24304@mercury.ccil.org> <5128EE1B-28A2-4D5E-AE32-BEC6652DF1A1@tfeb.org> <20140110171819.GA14513@mercury.ccil.org> <8F58DE51-60E5-4E41-AAEF-78CAC3C08DBC@tfeb.org> <20140113070543.GC22593@mercury.ccil.org> <9D0D12F6-B198-4793-8501-E366FC7E5CB1@tfeb.org> <20140113161506.GA31756@mercury.ccil.org> Message-ID: <20140113181635.GA12718@mercury.ccil.org> 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 From doug at cs.dartmouth.edu Fri Jan 10 07:43:07 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 09 Jan 2014 16:43:07 -0500 Subject: [TUHS] History of chown semantics Message-ID: <201401092143.s09Lh7Bp031238@stowe.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. From pepe at naleco.com Wed Jan 15 08:44:22 2014 From: pepe at naleco.com (Pepe) Date: Tue, 14 Jan 2014 23:44:22 +0100 Subject: [TUHS] History of chown semantics References: Message-ID: <000f01cf117a$2ba9bbe0$50651bac@naleco.com> 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. From imp at bsdimp.com Wed Jan 15 11:33:27 2014 From: imp at bsdimp.com (Warner Losh) Date: Tue, 14 Jan 2014 18:33:27 -0700 Subject: [TUHS] History of chown semantics In-Reply-To: <000f01cf117a$2ba9bbe0$50651bac@naleco.com> References: <000f01cf117a$2ba9bbe0$50651bac@naleco.com> Message-ID: 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 From lm at bitmover.com Wed Jan 15 11:43:23 2014 From: lm at bitmover.com (Larry McVoy) Date: Tue, 14 Jan 2014 17:43:23 -0800 Subject: [TUHS] History of chown semantics In-Reply-To: <000f01cf117a$2ba9bbe0$50651bac@naleco.com> References: <000f01cf117a$2ba9bbe0$50651bac@naleco.com> Message-ID: <20140115014323.GC15672@bitmover.com> 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 From cowan at mercury.ccil.org Wed Jan 15 12:13:55 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Tue, 14 Jan 2014 21:13:55 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <20140115014323.GC15672@bitmover.com> References: <000f01cf117a$2ba9bbe0$50651bac@naleco.com> <20140115014323.GC15672@bitmover.com> Message-ID: <20140115021355.GB27115@mercury.ccil.org> 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 From cnehren+tuhs at pobox.com Wed Jan 15 14:02:34 2014 From: cnehren+tuhs at pobox.com (Chris Nehren) Date: Tue, 14 Jan 2014 23:02:34 -0500 Subject: [TUHS] History of chown semantics In-Reply-To: <20140115021355.GB27115@mercury.ccil.org> References: <000f01cf117a$2ba9bbe0$50651bac@naleco.com> <20140115014323.GC15672@bitmover.com> <20140115021355.GB27115@mercury.ccil.org> Message-ID: <20140115040234.GF75847@eschaton.local> 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 From usotsuki at buric.co Wed Jan 15 14:39:38 2014 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 15 Jan 2014 04:39:38 +0000 (UTC) Subject: [TUHS] History of chown semantics In-Reply-To: <20140115040234.GF75847@eschaton.local> References: <000f01cf117a$2ba9bbe0$50651bac@naleco.com> <20140115014323.GC15672@bitmover.com> <20140115021355.GB27115@mercury.ccil.org> <20140115040234.GF75847@eschaton.local> Message-ID: 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. From tuhs at cuzuco.com Thu Jan 16 18:56:05 2014 From: tuhs at cuzuco.com (Brian S Walden) Date: Thu, 16 Jan 2014 03:56:05 -0500 (EST) Subject: [TUHS] History of chown semantics Message-ID: <201401160856.s0G8u5fe021668@cuzuco.com> 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 > > 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. >