9 Jan
2014
9 Jan
'14
10:59 a.m.
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
9 Jan
9 Jan
12:46 p.m.
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.
2:56 p.m.
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(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
3:17 p.m.
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
3:31 p.m.
On Thu, Jan 9, 2014 at 10:17 AM, Tim Bradshaw <tfb(a)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
6:31 p.m.
There's no real point in restricting the chown program if the system call
remains executable by non-root.
-----Original Message-----
From: tuhs-bounces(a)minnie.tuhs.org [mailto:tuhs-bounces@minnie.tuhs.org] On
Behalf Of Dario Niedermann
Sent: Thursday, January 9, 2014 1:18 PM
To: tuhs(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
6:48 p.m.
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(a)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(a)minnie.tuhs.org [mailto:tuhs-bounces@minnie.tuhs.org]
On
Behalf Of Dario Niedermann
Sent: Thursday, January 9, 2014 1:18 PM
To: tuhs(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
7:48 p.m.
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(a)ccc.com>
Subject: Re: [TUHS] History of chown semantics
Date: January 9, 2014 10:48:04 AM PST
To: Ron Natalie <ron(a)ronnatalie.com>
Cc: TUHS main list <tuhs(a)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(a)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(a)minnie.tuhs.org [mailto:tuhs-bounces@minnie.tuhs.org] On
Behalf Of Dario Niedermann
Sent: Thursday, January 9, 2014 1:18 PM
To: tuhs(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
7:52 p.m.
On Thu, Jan 9, 2014 at 2:48 PM, Armando Stettner <aps(a)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...
6:55 p.m.
On Jan 9, 2014, at 11:18 AM, Dario Niedermann wrote:
Il 09/01/2014 alle 15:56, Clem Cole ha scritto:
chown(2) has to do the enforcement. chown(1) or the filesystem doing it doesn't help
so much.
Warner
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. 
10 Jan
10 Jan
4:20 p.m.
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(a)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(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
9 Jan
9 Jan
5:01 p.m.
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/2Ty…
https://groups.google.com/forum/#!original/comp.unix.questions/I1nkZGl8Hl0/…
(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.
6:40 p.m.
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(a)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/2Ty…
https://groups.google.com/forum/#!original/comp.unix.questions/I1nkZGl8Hl0/…
(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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
7:13 p.m.
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(a)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.
8:19 p.m.
On Thu, Jan 9, 2014 at 9:13 AM, John Cowan <cowan(a)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
8:43 p.m.
On Jan 9, 2014, at 1:19 PM, Tim Newsham wrote:
On Thu, Jan 9, 2014 at 9:13 AM, John Cowan
<cowan(a)mercury.ccil.org> wrote:
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
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.
10 Jan
10 Jan
10:09 a.m.
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).
5:18 p.m.
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(a)ccil.org
--Judge Blagden http://www.ccil.org/~cowan
12 Jan
12 Jan
9:19 p.m.
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.
13 Jan
13 Jan
7:05 a.m.
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(a)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)
10:37 a.m.
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.
4:15 p.m.
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
4:53 p.m.
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(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
6:16 p.m.
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(a)ccil.org
--DeXiderata by Sean McGrath
9 Jan
9 Jan
10:57 p.m.
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@laposte.net
3754
days inactive
3758
days old
26 comments
13 participants
participants (13)
-
Armando Stettner -
Clem Cole -
Cyrille Lefevre -
Dario Niedermann -
Ed Carp -
Jeremy C. Reed -
John Cowan -
Ron Natalie -
Ronald Natalie
-
SZIGETI Szabolcs -
Tim Bradshaw -
Tim Newsham -
Warner Losh