|
Grex > Coop11 > #7: Grex vs. Malthus, round Sixty-Five Thousand, Five Hundred and Thirty-Six |  |
|
| Author |
Message |
| 25 new of 74 responses total. |
valerie
|
|
response 23 of 74:
| 
Jul 11 22:53 UTC 1998 |
This response has been erased.
|
arthurp
|
|
response 24 of 74:
|
Jul 12 03:05 UTC 1998 |
I think that wording would do a good job in newuser.
This is a bit techie, but does the file system have room in its
structures for longUIDs? We would have to mkfs anyway. But would we
have to create custom file system drivers?
|
srw
|
|
response 25 of 74:
|
Jul 12 05:02 UTC 1998 |
oops, the link I typed in resp:21 exposed a backtalk bug. It should have
worked and pointed to resp:12 . I am fixing the bug, which was caused by
the comma following the link, and the link will work once a new backtalk
is installed here.
picospan users please ignore - sorry for the drift -
The backtalk strategy of providing access to users without requiring an
account was well thought out, I believe. Asking people to take out an
account poses a barrier for many people. With this feature, they can see
what might be in store for them if they take out an account. They are
urged to do so. It was not so much intended to reduce the number of
abandoned accounts (wlthough it should do that) but to attract people
who would otherwise not come in.
|
mdw
|
|
response 26 of 74:
|
Jul 12 07:39 UTC 1998 |
If we were going to stick with sunos, we'd have to do a *lot* of
hackery. However, Solaris 2.6 does in fact share a "compatible" on-disk
filesystem layout with SunOS. The trick they use is they store the long
UID & GID at offsets +116, +120 in the on-disk inode, & store
0xffff,0xffff at offsets +4, +6, the old short uid/gid slots. One of
the many bits of kernel hackery that we'd have to do to sunos would be
to do something about the code in SunOS that *does* use these slots for
something else--"i_delaylen" and "i_nextrio".
openbsd shares very similar filesystem code with sunos, and may be very
nearly compatible. It, too, has support for long uids, but they're stored
in +112,+116, and there doesn't seem to be any kernel code to deal with
"old" filesystems. Instead, fsck contains logic to copy the old UIDs to
the new spots (apparently, without even asking.)
|
jared
|
|
response 27 of 74:
|
Jul 12 15:30 UTC 1998 |
I'd recommend saving your pennies and just buying some big fancy PC,
setting up some sort of *BSD on it, that you have full sources to,
and do it that way. 1) Replacement hardware is easy to find
2) Full source to OS and all its drivers is great for doing local hacks
3) despite (insert marcus paranoia about someone hardware hacking system),
there quickly come out OS patches for stuff like the 0xf00f stuff that
prevent any such attack.
|
mdw
|
|
response 28 of 74:
|
Jul 13 08:17 UTC 1998 |
You've a lot more faith in intel than me. Nevertheless, I would agree
it's likely grex will be on pci-bus in 1-2 hardware generations, and it
*may* be the case that linux a/o bsd will be secure enough at that
point. Given the # of really scary solaris bugs I keep hearing about, I
certainly don't feel especially comfortable in sticking with that.
|
rtgreen
|
|
response 29 of 74:
|
Jul 15 18:05 UTC 1998 |
I just entered a long response, and it appears it didn't get posted.
Mebbe I'll have the energy to re-type all that tomorrow, if it doesn't
find its way out of the bit-bucket.
|
dang
|
|
response 30 of 74:
|
Jul 16 17:01 UTC 1998 |
What about Kerberos? Would that solve our uid problem?
|
dpc
|
|
response 31 of 74:
|
Jul 16 19:34 UTC 1998 |
I like your suggestion in #23, valerie!
|
janc
|
|
response 32 of 74:
|
Jul 17 12:43 UTC 1998 |
I don't think Kerberos will have any effect on the UID problem. The
limitation is in the kernel, not in the passwd file.
|
jared
|
|
response 33 of 74:
|
Jul 17 19:58 UTC 1998 |
correct. kerberos is just a way to do user-auth, and it's os independent,
which means janc is correct.
as for marcus, and his paranoia, i'd be more concerned for solaris than
for intel. count the number of show-stoping hardware bugs in intel hardware
where the os is free. count the number of show-stoping hardware bugs where
the os is expensive, support is expensive, and you have to pay for some
patches, and you don't get src without boku bucks.
basically, all your paranoia about solaris and all can be taken care of by
getting OpenBSD or something, and spending a weekend reading the source,
hacking what you need into it over the next week or two, then anything
new that comes out you can patch against yourself, or use vendor
patches, rather than *having* to wait for sun to come out w/ a patch.
sun hasn't realized how to code yet and avoid buffer overflows. nor
have many people actually, they're not sgi, which by definition,
if you have an account, you have root, but they don't lock down on stuff
like openbsd does. (Note, i don't even run openbsd, but
they ara paranoid security folks, see http://www.openbsd.org/security.html)
|
janc
|
|
response 34 of 74:
|
Jul 17 21:15 UTC 1998 |
Though there are sparc versions of OpenBSD, and, according the the
developers "can be quite reliable depending on the configuration".
However, it does NOT run on Sun 4/600 systems.
|
jared
|
|
response 35 of 74:
|
Jul 18 16:46 UTC 1998 |
correct. the PC platform is the next logical choice for you to move to.
|
mdw
|
|
response 36 of 74:
|
Jul 19 07:57 UTC 1998 |
I agree the openbsd folks sound quite promising.
My reservations regarding intel based hardware still remain however.
Just the other day I saw some sort of *new* linux program that seems
intended to cause some sort of hardware exception (and crash the
machine). This is where the i386 really shows its weakness: the i386
has an extremely complex architecture, and all of these loose ends show
up in the exceptions you need to be able to handle. Just to add insult
to injury, the intel documentation is nearly useless in terms of
decoding all these exceptions--you basically need to try them all out
yourself, and see what happens, and this is the very worst sort of
kernel debugging to do, because you're basically dealing with the
machine where it gives you the least clues as to what went wrong. I
have *never* seen any intel OS that wasn't fairly trivial to crash. I
never made a concerted effort either, these were just things I *ran
into* doing quite different other stuff. With SCO Xenix (yup, it's
*ancient* history) -- I could crash it by doing a "return from
interrupt" with the wrong stuff on the stack (reti *is* a legal
instruction, even from so-called "user mode" (which doesn't really exist
on the intel, but that's a whole 'nuther story.). With freebsd, I could
crash it by trying to do a "ptrace" with a word that crossed a page
boundary. I don't know about the "reti" case, but I see that the ptrace
bug, at least, is fixed in openbsd.
For a while, I had mklinux running on a Macintosh (until the hard disk
died). This was an early version of mklinux - so it was missing the
years and years of experience everyone has had with the intel platform.
It was also more stable than any of the intel versions I've used.
*This* is the difference a clean architecture makes.
I'm still waiting for the vandals to find the "holy grail" bug in the
pentium series - the instructions that allow any "user mode" program to
read/write "kernel" memory. I'm confident it's only a matter of time.
|
jared
|
|
response 37 of 74:
|
Jul 19 14:30 UTC 1998 |
oh yeah, once they find the "holy grail" instruction, sure, the world is
over, but ya know what, instead of being paranoid about that, i'd be more
concerned about some stupid userland program or libc bug that allows
that because of poor bounds-checking.
and with your holy-grail paranoia, when is it going to be found in the
sparc platform? ultrasparc? 68030, everything.. ack!!!! lets let my
paranoia drive me away from any platform. that's the bright move.
The other thing you can do (oh no, another not-well-tested platform),
is use a Dec Alpha, those can take the same PCI bus cards as intel
(and the PCI Ultrasparcs), and have better handling of things such as no
video card, which intel boxes can't handle well, and it has a real
rom monitor. This would actually be a good choice also. The problem
with intel hardware is the fact that it's designed to have a monitor
and keyboard all the time. Although you can boot without them, if
your cmos becomes corrupted, you won't boot until someone gets back
there and fixes it. this can be avoided with headless boxes such as
sparcs, and alphas.
(yes, there are others that do headless well, but i'm not going to go
much further there).
|
mdw
|
|
response 38 of 74:
|
Jul 19 22:07 UTC 1998 |
The thing is, the 68030, sparc, powerpc, etc., platforms *are* different
than intel. *All* of these cpu's have much more modern design
methodology in them. The intel design methodology basically dates from
about 1960 -- the chip architecture is pretty obviously pre-GPR, and
even the IBM 7094 has a more regular instruction set. It's worse than
that even -- until the pentium II, intel processors weren't microcoded,
but used "random logic" to implement the instruction set. I've heard
that the famous intel FP bug wasn't an actual logic bug, but was in fact
an analog layout glitch.
There are also PCI bus powerpc machines, and PCI bus sparc machines.
(In fact, I have one of each in my office now...) That's why I said it
was a pretty safe bet that grex would end up on PCI bus at some point.
|
scg
|
|
response 39 of 74:
|
Jul 20 06:44 UTC 1998 |
It's worth noting that with the 0xf00f bug, most the the PC Unix systems had
patches out to trap the instruction within a few days, before people had time
to do major damage with it.
|
mdw
|
|
response 40 of 74:
|
Jul 20 14:39 UTC 1998 |
With the FP bug, intel *sat* on the bug for a year. After the bug was
popularized, intel was pretty recalcitrant about replacing the affected
CPU's. There is no patch for the FP bug.
|
jared
|
|
response 41 of 74:
|
Jul 25 10:21 UTC 1998 |
I like the way marcus brings up when you're doing scientific divison in
this item.
Yes, intel replaced those chips only because of a class-action suit
against them. I'm sure of that. But what percentage of the public
was really affected by this bug? Less than .01%, those were the folks
that should have really been getting the swapped cpus, not kids playing
doom.
And what CPU number was the pentium for intel? the FP+0xf00f bugs are
the only ones i know of. Want me to start listing the bugs that
have to be coded around in the sparc cpus? I can go dig up a list,
we can really start comparing, marcus. Maybe we could use one of
those as your "holy grail" bugs in the right way. It's more
likeley to have a bug not be found in the sparc CPUs because of
lack of exposure. We can't really say that about the intel ones,
I think they get a *little* more exposure than the others. How
many people are using your powerpc, 680x0 cpus in direct ratio to
intel x86 based cpus? Not many in comparision.
|
devnull
|
|
response 42 of 74:
|
Sep 28 00:46 UTC 1998 |
It appears that netbsd will support the 4/600; I guess openbsd doesn't.
I have not seen any convincing argument of why anyone would prefer openbsd
over netbsd (openbsd claims to care more about security, but I haven't seen
any solid evidence that in practice openbsd is more secure than netbsd).
(It has certainly been my experience that netbsd is more immune to cracker
attacks than debian.) As far as I can tell, the people working on netbsd
are probably more competent in general than the openbsd people.
|
saw
|
|
response 43 of 74:
|
Sep 28 21:02 UTC 1998 |
Let me just say that I have found out FreeBSD handles a LOT better than
Linux. Linux is fine for a home box where you won't have a lot of
traffic, it's what I use on my home PC. But, Jared can tell you, when
he switched nether from Linux to FreeBSD (without changing the computer
itself, he only changed OS) it made a BIG difference. It could handle tons
of users online at once just fine. Also, I've heard that anything newer
than Red Hat v4.2 isn't good at all-- and I could get practically NOTHING
to compile under RedHat 5.1 ..
|
dang
|
|
response 44 of 74:
|
Sep 30 17:22 UTC 1998 |
(5.1 has a hacked pre-release version of the 2.0.34 kernel. Get a real
version and everything compiles fine.)
|
saw
|
|
response 45 of 74:
|
Oct 1 01:59 UTC 1998 |
Well, that explains how RH got the 2.0.34 kernel onto their CD's so quickly
after it was released. By the time I got my CD though 2.0.35 was out, and
I tried using that but didn't really fool with compiling stuff under it. I
like Slackware better.
|
gorwell
|
|
response 46 of 74:
|
Apr 12 03:24 UTC 1999 |
Has a non-paying user I would like to express that I would like to
still use this system to email and bbsing
Because right now I have very little money.
I like to go on party because talking to people on m-net and grex
is mighty fun I don't think that tell people that you need to
pay to email is a good idea
60 days is good idea, after then reap them
It's to bad if they don't relogin again after 60 days
90 days is to long.
|
jiffer
|
|
response 47 of 74:
|
Apr 12 18:27 UTC 1999 |
I like the concept of 90 days. I could be gone for a summer (e.i. I am
talking about the students) and they could come back still with their
account.
|