496 lines
21 KiB
Plaintext
496 lines
21 KiB
Plaintext
Subject: Linux-Development Digest #535
|
|
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
|
|
To: Linux-Development@senator-bedfellow.MIT.EDU
|
|
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
|
|
Date: Thu, 10 Mar 94 07:13:04 EST
|
|
|
|
Linux-Development Digest #535, Volume #1 Thu, 10 Mar 94 07:13:04 EST
|
|
|
|
Contents:
|
|
Re: YP or NIS for linux? (Peter Eriksson)
|
|
Re: YP or NIS for linux? (Peter Eriksson)
|
|
Re: AMD 486DX problem (with Linux?) (Michael Bongartz)
|
|
STRAW POLL: Linux groups automonitoring (Ron "Asbestos" Dippold)
|
|
Problem with NET-2 and Winsock Gopher/HTTP clients? (Steven Kirby)
|
|
Re: AMD 486DX problem (with Linux?) (Peter Herweijer)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: peter@ifm.liu.se (Peter Eriksson)
|
|
Subject: Re: YP or NIS for linux?
|
|
Date: 8 Mar 1994 14:58:08 +0100
|
|
|
|
jfh@rpp386 (John F. Haugh II) writes:
|
|
|
|
>In article <2l2qi7$o5f@celsius.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes:
|
|
>>Ah and before someone says that SunOS 5 isn't the definite answer, then
|
|
>>I'd like to point out that I've been modelling NYS after the SunOS 5
|
|
>>model from the beginning?
|
|
|
|
>[ ... ]
|
|
|
|
>>(One can use "fputspent()" to write to a shadow file).
|
|
|
|
>Uh, there is no fputspent() in SunOS 5. And the only reason you have
|
|
>it in your code is to remain "compatible" with my code. Furthermore,
|
|
>there is no "fputspnam()" or any other random update code in SunOS 5.
|
|
|
|
Notice that '[ ... ]' part above? I did *not* say NYS would be contain
|
|
just the stuff in SunOS 5 and nothing else.The "fputspent()" is one of
|
|
many additions (some to have some compatibility with your code, atleast
|
|
that was my original intention).
|
|
|
|
>The reasons this is a bogus answer are legion, and I will gladly post
|
|
>a list if you insist.
|
|
|
|
>What you are doing is making it up as you go. Go read Brooke's
|
|
>"Mythical Man Month" for a description of the ultimate results.
|
|
|
|
:-)
|
|
|
|
You're really funny, did you know that? Why do I get the feeling your
|
|
feelings are hurt because I don't use your shadow stuff in NYS?
|
|
|
|
(The major reason was that at the time when I wrote that stuff JFH's
|
|
shadow library wasn't LGPL'd. Another big reason was that I wanted
|
|
a set of *clean* functions and header files without all the compatibility
|
|
stuff for 4711 different unixes that pollutes JFH's shadow library).
|
|
|
|
Btw, what's stopping you from writing your own NYS library with your
|
|
shadow stuff if you think my stuff is so bogus, wrong and totally useless?
|
|
|
|
/Peter (peter@ifm.liu.se)
|
|
|
|
Ps, I'm always open for suggestions for improvements if they are presented
|
|
in a nice manner. If some jerk starts a request for improvement by flaming
|
|
me, then I can promise you I'll completely disregard his/her opinions.
|
|
|
|
What I'm considering is to add a function named __getspnam() (or fgetspnam()
|
|
or whatever) that will read the shadow file only, and nothing else.
|
|
|
|
But the basic getspnam() function will stick to getting it's information
|
|
from /etc/shadow, /etc/passwd, YP, NIS+, Kerberos or whatever (as specified
|
|
in the "/etc/nsswitch.conf" configuration file).
|
|
|
|
------------------------------
|
|
|
|
From: peter@ifm.liu.se (Peter Eriksson)
|
|
Subject: Re: YP or NIS for linux?
|
|
Date: 8 Mar 1994 16:38:51 +0100
|
|
|
|
jfh@rpp386 (John F. Haugh II) writes:
|
|
|
|
>In article <2l2qi7$o5f@celsius.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes:
|
|
>>It's not a bug. It was designed that way. Oh, and it can't even
|
|
>>determine if the entry exists in the local /etc/shadow or /etc/passwd
|
|
>>or if it comes over the network from a remote YP servers 'passwd' map
|
|
>>or if it comes from a NIS+ servers passwd database or ...
|
|
|
|
>Then it is a bug.
|
|
|
|
Then you and I have different definitions of bugs.
|
|
|
|
|
|
>The SVR4 (the real ones, not the ones I ship with Shadow) say
|
|
|
|
> "The getspnam routine searches from the beginning of the file
|
|
> until a login name matching name is found, and returns a pointer
|
|
> to the particular structure in which it was found. ... If an
|
|
> end-of-file or an error is encountered on reading, or there is
|
|
> a format error in the file, these functions return a null
|
|
> pointer and set errno to EINVAL."
|
|
|
|
>You aren't returning the proper result, therefore your design is busted.
|
|
>SVR4 is the base for the /etc/shadow file functions in both my implemenation
|
|
>and the Solaris 2.0 versions. You are incompatible.
|
|
|
|
Huh? I didn't know your version of Shadow was NameServiceSwitch-aware.
|
|
getspent() in Solaris 2 uses the /etc/nsswitch.conf file to find out
|
|
from which service to get the shadow information. In the YP (NIS version 2)
|
|
case it gets it from the Passwd map. I have only extended this to cover
|
|
the case of files also.
|
|
|
|
|
|
>>The one major reason for doing it like this is that it should be transparent
|
|
>>to the application if the password information for a user comes from
|
|
>>/etc/shadow or /etc/passwd or from YP or NIS+ or something else.
|
|
|
|
>WRONG! If you do this for /etc/shadow information the application (which
|
|
>might be one that updates /etc/passwd, say chfn for example) doesn't know
|
|
>where to put the information BACK to.
|
|
|
|
Bullshit. Sure, chfn has to use some other way to find out from which source
|
|
it got it's information, but it has to do that anyway since the information
|
|
might come from YP (in which case it has to talk to a remote rpc.yppasswd
|
|
server to change the information) or NIS+ (in which case it has to do an
|
|
authenticated RPC call to to NIS+ server to modify the information).
|
|
|
|
|
|
>Automatically giving the encrypted password when you call getpw*() is a
|
|
>huge security hole waiting to happen. The way I found it was a security
|
|
|
|
Agreed. But NYS does *NOT* give the encrypted password when you call
|
|
getpw*(). Where on earth did you get that impression? It's the getsp*()
|
|
functions that fall-back to reading /etc/passwd if /etc/shadow doesn't
|
|
exist, not the other way around.
|
|
|
|
Ah, I just noticed one improvement I'll add and that is that if the
|
|
file /etc/shadow exists, but is read-protected then the getsp*()
|
|
functions won't fall back to reading /etc/passwd (or perhaps they
|
|
will do that but return "*" in the passwd field, hmmm. Have to make up
|
|
my mind on that issue).
|
|
|
|
|
|
>hole was to run Shadow with AUTOSHADOW turned on in an earlier version
|
|
>of some of the commands and watch as my encrypted passwords all started
|
|
>to turn up. By separating "shadow" information (which is sensitive)
|
|
>from "normal" information (which anyone can get) you insure that there
|
|
>is no unintentional exportation of privileged information. This is
|
|
>Information Security 101.
|
|
|
|
>>Btw, what's wrong with the following code if you desperately wants
|
|
>>to read the _file_ /etc/shadow to see what's in it.
|
|
|
|
>There is no "fgetspnam()"?
|
|
|
|
Like wow man. Big problem. Sigh. The next version of NYS will contain
|
|
a set of functions __setspent(), __endspent(), __getspent(), __getspnam()
|
|
that will only read "/etc/shadow" and nothing else.
|
|
|
|
|
|
>>>The second isn't really a bug and the regular C library has this same
|
|
>>>shortfall. The result of this is that if you have a large /etc/passwd
|
|
>>>file it takes longer for the last user in the file to login than the
|
|
>>>first.
|
|
>>
|
|
>>One easy way to "fix" that problem is to simply start a local YP server.
|
|
>>And if you have that much users that it takes a long time to read
|
|
>>/etc/passwd then you probably have multiple machines also and would
|
|
>>like to use some kind of Network Information Service like YP, NIS+ or
|
|
>>Hesiod.
|
|
|
|
>There are quite a few assumptions in there which aren't suppored by
|
|
>any facts. I can imagine quite a few situations where there are enough
|
|
>users in /etc/passwd that user lookups become problematic. And forcing
|
|
>the users to setup YP servers doesn't seem like a nice way to prevent
|
|
|
|
Setting up an YP server doesn't have to be complex. If the YP server
|
|
is properly written all it would need would be the following two
|
|
lines in /etc/rc (or the equivalent):
|
|
|
|
/usr/sbin/rpc.portmap
|
|
/usr/sbin/rpc.ypserv
|
|
|
|
(Ideally it would automatically build GDBM/BerkeleyDB databases from the
|
|
text files when it detects that the files have been modified. Ie, no need
|
|
for "cd /var/yp; make").
|
|
|
|
|
|
>the system from being complex, or reliable. What are you going to
|
|
>propose when ypserv doesn't and ypbind gets hung as a result?
|
|
|
|
Sorry, I can't parse what you're talking about here.
|
|
|
|
If one is using NYS and ypserv or ypbind dies/hangs then one simply
|
|
logs in as root (since the root passwd and things are in
|
|
/etc/passwd+/etc/shadow and one keeps "files" ahead of "yp"
|
|
in "/etc/nsswitch.conf" line for "passwd") and then restarts
|
|
ypserv and/or ypbind if needed.
|
|
|
|
|
|
>>But I'll probably add some kind of DBM support to NYS as soon as I
|
|
>>have some spare time. It will not be using DBM/NDBM but probably
|
|
>>either GDBM or the new Berkeley DB database engine.
|
|
|
|
>Why not use NDBM's interface? GDBM has an NDBM emulation mode (that
|
|
>what I use for Shadow on this system ...) and every BSD system on the
|
|
>planet has NDBM already. Sounds like you're trying to be INcompatible
|
|
>on purpose.
|
|
|
|
NYS isn't targeted at every BSD system on Earth. It's targeted at
|
|
Linux primarily. The way I see it Linux has a chance to do it right
|
|
instead of having to suffer from the same stupid limitations as some
|
|
other have.
|
|
|
|
From the manual page of "ndbm" from a SunOS 4 machine:
|
|
|
|
The sum of the sizes of a key/content pair must not exceed
|
|
the internal block size (currently 4096 bytes). Moreover
|
|
all key/content pairs that hash together must fit on a sin-
|
|
gle block. dbm_store() will return an error in the event
|
|
that a disk block fills with inseparable data.
|
|
|
|
Need I say more? This limits the number of (for examples) group members
|
|
in a NDBM-version of /etc/group to prox 4096/(sizeof(username)+1), less
|
|
than ca 1000 users. Ever wondered why Sun's YP has the same limitation
|
|
with regard to the number of users in a group...?
|
|
|
|
I'd much rather use the new Berkeley DB (that is used in the new
|
|
Sendmail v8) that doesn't have these stupid limitations.
|
|
|
|
/Peter
|
|
---
|
|
Peter Eriksson <peter@ifm.liu.se> Linkvping University,
|
|
Systems Administrator Department of Physics,
|
|
Phone: +46 13 28 27 86 S-581 83 Linkvping, Sweden
|
|
|
|
------------------------------
|
|
|
|
From: micha@mubo.saar.de (Michael Bongartz)
|
|
Subject: Re: AMD 486DX problem (with Linux?)
|
|
Date: Mon, 7 Mar 1994 20:39:50 GMT
|
|
|
|
On Sun, 6 Mar 1994 21:16:02 GMT in comp.os.linux.development, John McCluskey (jbm@speedy.login.qc.ca) wrote:
|
|
: micha@mubo.saar.de (Michael Bongartz) writes:
|
|
|
|
: >On 05 Mar 1994 05:42:38 GMT in comp.os.linux.development,
|
|
: > Gregory McKesey (mckesey@imaphics.prior.com) wrote:
|
|
|
|
: >: I have found an annoying problem with the AMD 486DX chip and
|
|
: >: Linux that is leading me to believe that there may be a compatibility
|
|
: >: problem with this chips math functions. One reported symptom is
|
|
: >: that ghostscript dies during initialization. While trying to track
|
|
: >: down the problem I booted my kernel with the no387 option (using Lilo).
|
|
: >: To my surprise ghostscript worked in this configuration.
|
|
|
|
: >: I decided to investigate further, and found a problem with
|
|
: >: single precesion (ie float) multiplys. The following is a sample
|
|
: >: program that illustrates the problem.
|
|
|
|
: >I couldn't resist testing this on my AMD 486 DX2/66 system:
|
|
|
|
: >micha@moko|~/tmp>cc -o float float.c
|
|
: >micha@moko|~/tmp>float
|
|
: >1.312500 * 7.999900 =10.499868
|
|
: >1.312500 * 7.999900 =10.499869
|
|
: >Test succeeded!
|
|
|
|
: >It seems that this bug doesn't exist on all AMD chips.
|
|
|
|
: Ditto. My AMD-486DX40 yields exactly the same results as above. My
|
|
: CPU is marked with the "Windows Compatible Logo". I bought it last month.
|
|
: It looks like the recent production of AMD is clean.
|
|
|
|
Mine too has this Windows logo :-(((
|
|
|
|
It's about two weeks old.
|
|
|
|
Micha
|
|
|
|
--
|
|
A bad ad can ruin your whole day!
|
|
|
|
EMail: micha@mubo.saar.de /\/\ University: bongartz@cs.uni-sb.de
|
|
Voice: 0681/556-54 / \ Fax + Modem (ZyX 19k2): +49 681 556-34
|
|
SnailMail: Michael Bongartz, Hohe Wacht 18, 66119 Saarbruecken, Germany
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: news.groups,comp.os.linux.announce,comp.os.linux.misc,comp.os.linux.help,comp.os.linux.admin
|
|
From: rdippold@qualcomm.com (Ron "Asbestos" Dippold)
|
|
Subject: STRAW POLL: Linux groups automonitoring
|
|
Reply-To: voting@qualcomm.com (Ron Dippold Voting Alias)
|
|
Date: Wed, 9 Mar 1994 20:24:31 GMT
|
|
|
|
[]
|
|
STRAW POLL
|
|
Linux groups automonitoring
|
|
|
|
Votes must be received by 23:59:59 UTC, Thu 17 March 1994.
|
|
|
|
This vote is being conducted by a neutral third party. For voting
|
|
questions only contact rdippold@qualcomm.com. For questions about the
|
|
proposal contact Ian Jackson <iwj@cam-orl.co.uk>.
|
|
|
|
|
|
PROPOSAL (Ian)
|
|
|
|
I propose to set up an auto-response daemon which will scan the
|
|
newsgroups comp.os.linux.misc, .help, .development and .admin.
|
|
|
|
It will send email to the posters of any messages which either
|
|
(a) do not include one of a set or recognised keywords in the
|
|
Keywords line or
|
|
(b) are crossposted between two or more of the groups listed above,
|
|
without a Followup-To header being used to direct followups
|
|
into no more than one of those groups (plus perhaps one or more
|
|
groups outside the comp.os.linux hierarchy).
|
|
|
|
The email will be a brief, friendly introduction to the newsgroup in
|
|
question and the hierarchy in general - probably based on Matt Welsh's
|
|
introduction to the comp.os.linux hierarchy and my daily postings in
|
|
comp.os.linux.misc and .help.
|
|
|
|
It will say where the FAQs are, why to read them, and where to get
|
|
them.
|
|
|
|
It will also say why the message has been sent to the user, and give a
|
|
brief explanation of why Keywords are a good thing and/or why
|
|
crossposting is a bad thing (as appropriate).
|
|
|
|
I would determine the set of allowable keywords with assistance from
|
|
the Linux community; I expect the set to change quite frequently, and
|
|
there to be a dozen or two at most.
|
|
|
|
The existence of my daemon would be documented in a regular posting to
|
|
the groups (preferably as part of an existing regular posting).
|
|
|
|
Note that this proposal will NOT prevent anyone from posting and does
|
|
not involve marking the groups as moderated.
|
|
|
|
I hope to be able to provide an email-to-news gateway that will be
|
|
allow users with retarded software to post with Keywords lines.
|
|
|
|
|
|
RATIONALE (Ian)
|
|
|
|
During the recent discussion in news.groups regarding my original
|
|
proposal to moderate col.* using a program, several people suggested
|
|
that perhaps many of the "poor" posts do not come from first-time
|
|
posters, and that therefore it would be sufficient to send email to
|
|
posters whose postings did not have one of a set of approved keywords.
|
|
|
|
Doing so would allow experienced users to start using killfiles to
|
|
read only postings they believe they would find interesting, based on
|
|
keywords, since any users posting without such keywords would be
|
|
informed by the daemon that and why their posting might not get the
|
|
attention they would wish for it.
|
|
|
|
|
|
HOW TO REPLY
|
|
|
|
Erase everything above the top "-=-=-=-" line and erase everything
|
|
below the bottom "-=-=-=-" line. Do not erase anything between these
|
|
lines and do not change the group names.
|
|
|
|
Give your name on the line that asks for it. For each group, place a
|
|
YES or NO in the brackets next to it to vote for or against
|
|
automonitoring as described above for that particular group. If
|
|
you don't want to vote on a particular group, just leave the space
|
|
blank. Don't worry about spacing of the columns or any quote
|
|
characters (">") that your reply inserts.
|
|
|
|
Then mail the ballot to: voting@qualcomm.com
|
|
Just Replying to this message should work, but check the "To:" line.
|
|
|
|
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
|
|
linux automoderation poll Ballot <luxp-0001> (Don't remove this marker)
|
|
|
|
Give your real name here:
|
|
|
|
Use YES or NO for each group to indicate support or opposition to
|
|
automonitoring for that group as described in the proposal above.
|
|
|
|
[Your Vote] Group
|
|
=======================================================================
|
|
[ ] comp.os.linux.misc
|
|
[ ] comp.os.linux.help
|
|
[ ] comp.os.linux.admin
|
|
[ ] comp.os.linux.development
|
|
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
|
|
|
|
Anything else may be rejected by the automatic vote counting program. The
|
|
votetaker will respond to your received ballots with a personal acknowledge-
|
|
ment by mail - if you do not receive one within several days, try again.
|
|
It's your responsibility to make sure your vote is registered correctly.
|
|
|
|
Only one ballot per person and per account will be counted. All
|
|
names, addresses, and votes are public.
|
|
|
|
|
|
--
|
|
All generalizations are false.
|
|
|
|
------------------------------
|
|
|
|
From: kirby@scarlett.libs.uga.edu (Steven Kirby)
|
|
Subject: Problem with NET-2 and Winsock Gopher/HTTP clients?
|
|
Date: 10 Mar 1994 11:39:54 GMT
|
|
|
|
Hey, y'all. This is kinda an oddball question, but it came up late last week
|
|
on the gn-main list for users of the GN Gopher/HTTP server. A little work
|
|
leads me to believe that we're looking at a glitch in NET-2, but I thought
|
|
I'd check here before I pester the NET-2 developers.
|
|
|
|
Here's the scenario. I'm running the Yggdrasil release of Linux (kernel p14),
|
|
and another site running Slackware (kernel version unknown, I forgot to ask)
|
|
has reported the same problem. We can serve Gopher/HTTP to X clients, Mac
|
|
clients, and OS/2 clients without problems. Same goes for curses clients.
|
|
However, when we attempt to serve Gopher/HTTP to any app that uses the
|
|
Winsock DLL (e.g., BCGopher, WinMosaic, Cello), some really odd stuff happens.
|
|
On occasion, we can move graphical images to the client without problems.
|
|
Usually, though, the transfer of data is not completed. The client shows that
|
|
the file has been moved, but nothing happens. No decompression, no pretty
|
|
pictures, nothing. It appears that there is some sort of timing problem with
|
|
Winsock clients who try to connect to a GN server running under Linux.
|
|
|
|
My first reaction was to blame the Winsock client, but all of the ones I've
|
|
tested work just fine with other systems. Plus, the other guy ran a sniffer
|
|
trace that seemed to indicate to him that the communication was timing out
|
|
from the Linux box. (I dunno how to read the trace report, but if anybody
|
|
wants to see it, let me know and I'll be happy to mail a copy.) I'm pretty
|
|
sure the problem ain't with GN, since I can use WinMosaic to connect to other
|
|
GN servers without trouble.
|
|
|
|
My conclusion is that we've probably uncovered a fairly minor bug in NET-2.
|
|
Does this seem reasonable, or have I missed more than my usual quota of
|
|
something? If it helps, my box is a 386-40 (we built it ourself) with 8 megs
|
|
of RAM and a Longshine LCS-8634 (NE2000 clone) ethernet board. The other guy
|
|
is also using an NE2000 clone, I think, so there is also a remote chance
|
|
that the problem is with the NE2000 driver and clone boards. I dunno.
|
|
|
|
Any advice/information will be most appreciated, especially if it will help me
|
|
figure out who to bother first with this problem.
|
|
|
|
Thanks!
|
|
|
|
--Steve
|
|
|
|
Steven Kirby University of Georgia kirby@scarlett.libs.uga.edu
|
|
|
|
|
|
------------------------------
|
|
|
|
From: pieterh@sci.kun.nl (Peter Herweijer)
|
|
Subject: Re: AMD 486DX problem (with Linux?)
|
|
Date: Thu, 10 Mar 1994 11:25:19 GMT
|
|
|
|
rm@eacpc4.tuwien.ac.at (Ralf Messerer) writes:
|
|
|
|
>There is no CPU bug. The only thing is that the number 7.9999
|
|
>can not be stored in the float format without loosing precision.
|
|
|
|
_Of course_ it loses precision. But the difference reported was far
|
|
larger than you'd expect from that.
|
|
|
|
The point still stands. I took the liberty of posting a short
|
|
summary and the test program to comp.sys.ibm.pc.hardware.chips so
|
|
that the folks out there can try it too. We'll see what happens.
|
|
Is it Linux? Is it GCC? Is it AMD? Or some obscure interaction
|
|
between the three?
|
|
|
|
Peter Herweijer
|
|
pieterh@sci.kun.nl
|
|
|
|
------------------------------
|
|
|
|
|
|
** FOR YOUR REFERENCE **
|
|
|
|
The service address, to which questions about the list itself and requests
|
|
to be added to or deleted from it should be directed, is:
|
|
|
|
Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
|
|
|
|
You can send mail to the entire list (and comp.os.linux.development) via:
|
|
|
|
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
|
|
|
|
Linux may be obtained via one of these FTP sites:
|
|
nic.funet.fi pub/OS/Linux
|
|
tsx-11.mit.edu pub/linux
|
|
sunsite.unc.edu pub/Linux
|
|
|
|
End of Linux-Development Digest
|
|
******************************
|