Subject: Linux-Development Digest #535 From: Digestifier 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 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 . 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 (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 ******************************