Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA02732; Wed, 13 Dec 95 19:25:30 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA21211; Wed, 13 Dec 95 19:25:32 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id TAA28100 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Wed, 13 Dec 1995 19:13:44 -0500 Message-Id: <199512140013.TAA28100@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Date: Wed, 13 Dec 95 19:13:40 EST Subject: Linux-Development-System Digest #114 Linux-Development-System Digest #114, Volume #2 Wed, 13 Dec 95 19:13:40 EST Contents: Re: Advices from user to developpers (Jari Soderholm) Simple (?) question: Kernel compile error message. (Henrik Soderstrom) Turn off SCSI-drives? (Andreas Berg) [Q] Any source available for memory management? (Chung-Kie Tung) Re: Threads - a better model? (William S. Gribble) Re: ld won't dynamically link libc.so.2.5.16 (Mathew G Monroe) Re: Linux Security - C2 and beyond (Albert Cahalan) Re: Module loading on demand ?? (Jacob Miner) Re: Linux Security - C2 and beyond (Joe Buck) Sharing swap & /tmp on one drive (Richard Jones) Re: Unable to resolve _doprint() function (Al Longyear) Re: Netscape/Mosaic for ELF (H. Peter Anvin) y (John James) Re: Linux ISO 7816 emulator (was: New Voyager) (Arnt Gulbrandsen) Linux ISO 7816 emulator (was: New Voyager) (Markus Kuhn) Are libc functions MT-safe? (Doug Kwan ~{9XUq5B~}) ---------------------------------------------------------------------------- From: jasoderh@ntc.nokia.com (Jari Soderholm) Subject: Re: Advices from user to developpers Date: 13 Dec 1995 14:22:07 GMT Ulises Alonso Camaro (alonso@bebe.eleinf.uv.es) wrote: : Hi all, : This article is an advice to the people that is working around X-windows : system and applications (thanks you very much to do things like these). : Fairly I'm not an expert but let me tell you that I think about it. : Linux is a very powerfull and a quite complete OS, but the hatefull WinDOS 95 : has a much better user's & program's interface (oriented object desktop, : connectivity between the programs: cut&paste....), maybe these features have : an high CPU & memory cost, and these aren't the reasons cause we choose Linux, : but this is the future, and I know that these things are very hard to imple- : ment but I would like to see Linux on top a lot of years cause I think this : that is the right way: more friendly applications; I think that a powerfull : & "unfriendly" application can be not used fully cause it's interface with : the user: easy to use, portable with other applications...... : Well I hope you understud my very poor english... ;) : That's all, I know that I didn't discovered nothing but I want remind you it. : : Thanks everybody, There is videodriver interface project going on, it will offer standard video interface for linux.. Take look at this nice project: http://www-public.rz.uni-duesseldorf.de/~becka/doc/scrdrv.html http://www.tu-chemnitz.de/~sse/scrdrv Jari ------------------------------ From: Henrik Soderstrom Crossposted-To: comp.os.linux,comp.os.linux.setup Subject: Simple (?) question: Kernel compile error message. Date: 13 Dec 1995 14:28:14 GMT Hi, I am seeing the following error message as one of the first messages when starting to compile the kernel (all versions, as far as I recall, 1.2.13, 1.3.xx up to 1.3.47): dnsdomainname: Unknown server error after that the compilation carries on and completes successfully so I've just ignored it for the time being. Would be interesting to know what it means though, haven4t a clue !? Can anyone enlighten me ? Is there a potential problem here ? Cheers /Henrik PS: The system is not configured for any networking or communications and am compiling with all those options disabled. ------------------------------ From: gf135@appl2.hrz.uni-siegen.de (Andreas Berg) Subject: Turn off SCSI-drives? Date: 13 Dec 1995 11:38:13 GMT How can I turn off SCSI-drives in Linux. The drives understand the SCSI-command START STOP UNIT ( 1b ), but I don't know how to use this under Linux. The SCSI-Programming-Howto tells only about programming generic SCSI-units. Is there a possibility to use the green-functions of the BIOS to do this? The normal HD-POWER-DOWN seems only to effect IDE-disks. Thanks in advance, Andreas. ------------------------------ From: tung@garfield.ee.ncku.edu.tw (Chung-Kie Tung) Subject: [Q] Any source available for memory management? Date: 13 Dec 1995 16:47:33 GMT [ Article crossposted from comp.os.linux.development.apps ] [ Author was Chung-Kie Tung ] [ Posted on 13 Dec 1995 16:46:26 GMT ] hi.... I am trying to using share memory to solve large data transfer between 2 process. Cause there is a limit of total segments of share memory, I plan to allocate one large share memory segment and do my own memory management. I think there maybe source available for this. (source can do memory management on a pre-allocated large memory block) Any help or information will be much appreciated.... tung@garfield.ee.ncku.edu.tw ------------------------------ From: grib@cs.utexas.edu (William S. Gribble) Subject: Re: Threads - a better model? Date: 12 Dec 1995 08:52:27 -0600 grilly@edwood (Nicolas Grilly) writes: > But I am surprised by the discussion about names of multi-threading API > functions. A great strength of Linux is its compliance with > POSIX. Does POSIX (or the Spec 1170) define a multi-threading API ??? Not only does POSIX define a thread API, but it is already available on Linux and support for it is being built into the Linux C library. The talk about kernel thread functionality is of basically zero significance to anyone except people who are actually implementing the POSIX thread spec at the user level. As you point out, kernel threads do have significance for an SMP machine, and that's being worked on. But the functionality to write preemptive multithreaded programs conforming to the POSIX thread API is there and has been there for I guess a couple of years now. I'm getting a little frustrated by all the people who keep insisting that Linux doesn't have threads, or that Linux thread support is somehow substandard! It ain't so, people. If you don't believe me, get the pthreads sources yourself and write some code: http://www.mit.edu:8001/people/proven/pthreads.html Bill Gribble ------------------------------ From: Mathew G Monroe Subject: Re: ld won't dynamically link libc.so.2.5.16 Date: Tue, 12 Dec 1995 02:46:41 -0500 Excerpts from netnews.comp.os.linux.development.system: 12-Dec-95 Re: ld won't dynamically li.. by Craig J Copi@ellis.uchic > > Why is this and why does ldconfig still make the (incorrect) symbolic > links of libc.so.5 -> libc.so.5.2.16 for you? > Because this is the standard on all other ELF systems. The linux developement team tried to improve on the standard, but gone back to the old method for compatibility. The link from libc.so.5 -> libc.so.5.2.16 is correct. ldconfig links the SONAME of libraries to their corisponding filenames. libc.so.5.2.16's SONAME is libc.so.5, so a link is created. SONAME and filenames of libraries are totally independant, it is considered good practice to make them close. Matt ------------------------------ From: albert@krakatoa.ccs.neu.edu (Albert Cahalan) Subject: Re: Linux Security - C2 and beyond Date: 13 Dec 1995 19:40:52 GMT >>>>> John F Haugh writes: >> If someone just wants to allow individual privlidge tracking, >> great. I like it. Getting rid of root completely (like NT) >> is just a way to pretend you are secure, which is not good IMHO. > Those of us who've spent a decade or more would like to > remind those of you who haven't that this issue was resolved > about the time you were born. > Getting rid of root goes a long way to improving the security > of a system. Whenever I (my credentials are that I am an > advisory programmer at IBM with 14 years of UNIX experience), > am asked to review subsystem code which has potential security > exposures, the first thing I want to know is did you manage > your privileges. Least privilege makes this much easier since > I know the complete set of privileges which may be abused. > Having worked on least-privilege kernels for nearly 7 years now, > I assure you it is a Very Good Thing. > You are free to impress me with your credentials, papers published, etc. I don't intend to try. Instead, I ask you to describe a system without root. Specifically: How does one install a new kernel? Remember that Linux hackers sometimes do this from a remote site! How does one fix a trashed filesystem? Repairs may include allocating/deallocating blocks, changing ownership, changing timestamps, mounting a corrupt (and hacked) filesystem read-only to copy off data, etc. Some people do this offsite too! How does the system administrator work? It seems that without a root user, all tools would need to be setperm (?) p1+p2+p3... What a complicated mess. Also, someone must set these permissions in the first place - not root, because root is gone. What is it like trying to compile things? Many tools assume a normal unix permission system, and could either fail to compile or crash when you run them. What about sendmail, samba, su, mtools, elm... What about X, DOSEMU, and all the SVGAlib programs? -- Albert Cahalan albert@ccs.neu.edu ------------------------------ From: jacob@nova.cnd.hp.com (Jacob Miner) Subject: Re: Module loading on demand ?? Date: 13 Dec 1995 16:46:20 GMT In article pope@edunet.dk (Povl H. Pedersen) writes: > Can you tell me why I can't insmod any modules in my 1.3.46 kernel > compiled with 2.7.2 as ELF. > > I get all sorts of linking errors. like: > edunet:/lib/modules/1.3.46/net# insmod dummy.o > ether_setup undefined > dev_kfree_skb undefined > dev_get undefined > register_netdev undefined > unregister_netdev undefined > kfree undefined > > > is there a newer insmod I need ? > I too am having the exact same problem, I am using kernel 1.3.45ELF, and gcc 2.7.2, and when I insmod I get undef errors all over... -- _ _ | | __ _| | _____ _ | |/ _` | |/ / _ \ jacob@cnd.hp.com Physical MOD-1 | |_| | (_| | < __/ Telenet (4479) Afternoons 1:00-5:00 _\___/_\__,_|_|\_\___|______________________________________________ ------------------------------ From: jbuck@synopsys.com (Joe Buck) Subject: Re: Linux Security - C2 and beyond Date: 13 Dec 1995 20:41:42 GMT mskuhn@cip.informatik.uni-erlangen.de writes: >There is absolutely no reason, why highly complex (= dangerous!!!) >programs like sendmail have to run with the same access control level >(root) as the all-powerful user. The deficiencies of sendmail have more to do with the architecture of sendmail itself than with problems with the Unix security model. Simply put, sendmail is an embarrassing botch. Its designer DELIBERATELY put back doors in it so he could get root access on other machines at Berkeley; these were supposed to be taken out, but instead a password was added (the old "wizard's password"). The debug hole similarly sprung from a back door. sendmail's functionality should be divided into small, manageable pieces, and the pieces can be designed in such a way that they immediately give up root privilege after completing the simple function that requires security. The SMTP daemon (which has to connect to a privileged port) has little in common with the local mail delivery agent; why are these in the same program? >Give your software only exactly the access right which it >requires and nothing more. Classical Unix and Linux currently provide >much too weak mechanisms for this policy. Fine. But other approaches granting limited privileges tend to be flawed in practice; moderate hacking skill often turns a VMS privilege into "all privileges". >The only real threat to single-user home PCs are binary-only trojan >horses, especially when PPP links to the rest of the world are >available. I am quite paranoid about running software like Netscape, >which I can get only as a binary and which I can not check because I >have no source code. "Paranoid" is an accurate word here. Netscape has a wildly volatile stock, and any security flaw found would cost them a billion dollars or so. There aren't going to be things that you're going to find with a casual inspection of the source. They haven't put in a nasty on purpose. If they did and it were found, their company would vanish in a puff of smoke. They are not insane. Similarly, many programs that are distributed in source form are written sloppily, in a way that is difficult to understand; there's plenty of room for flaws or nasties. Eric Allman (sendmail's author) gave the other sysadmins source to sendmail, and it had a back door that let him become root on their machines. Do you KNOW that every svgalib program you run is free of such back doors? They run setuid root; have you checked the source code? >Just one example, and no, this is not full paranoia mode: >the Win95 MSN client sends back to Microsoft large parts of your hard >disk without your knowledge and has been called for this reason a >serious trojan horse by many people. This story has been shown to be false. The information is only sent if the user clicks a form that sends it. -- -- Joe Buck (not speaking for Synopsys, Inc) ------------------------------ From: rwmj@doc.ic.ac.uk (Richard Jones) Subject: Sharing swap & /tmp on one drive Date: 13 Dec 1995 20:28:04 -0000 I've got a 200 Mb disk that I'd like to share between /tmp & swap. Put simply, I'd like to somehow share the space between swap and /tmp so that I can have upto 200 Mb /tmp+swap, but no fixed limit on either. The scheme I've come up with at present involves doing the following: 1. format the whole disk as swap 2. write a simple block device that just implements a ramdisk in virtual memory, rather like /dev/ram, but using virtual, not just physical memory, and allowing the size to increase arbitrarily (and shrink again) But there are some problems with this: firstly, I can't work out how to prevent the kernel from using the buffer cache on this device [- surely the kernel doesn't use the buffer cache on the ramdisk?] ... secondly no filesystem will let the underlying block device increase & decrease arbitrarily, but I don't want to have to write another ext2-compatible fs. Can anyone think of a way to do this? Rich. -- "The real tight interface is between the book and the reader - the world of the book is plugged right into your brain, never mind the [virtual reality] bodysuit" -- from The Age of Missing Information, by Bill McKibben. ------------------------------ From: longyear@sii.com (Al Longyear) Crossposted-To: comp.os.linux.development.apps Subject: Re: Unable to resolve _doprint() function Date: 12 Dec 1995 16:54:30 GMT The _doprint function was an old K&R function. Don't use it if you want to write portable, ANSI code. Use vfprintf() for the function. It even works with *BSD! Oscar E Masters writes: > I was attempting to compile/link the following routine using > linux 1.2.13 under Slackware Version 3 : >-------------------------------- > #include > #include > int errexit (format, va_alist) > char *format; > va_dcl > { > va_list args; > va_start(args); > fprintf(stderr,"stderr entered via call\n"); #ifdef I_WANT_OLD_TRASH > _doprnt(format, args, stderr); #else /* I want portable, ANSI code! */ vfprintf (stderr, format, args); #endif > va_end(args); > exit(1); > } >------------------------------- > Any ideas as to why i can't resolve this module. Perhaps it is because it is not in the Linux library. Linux is not based upon K&R C. It's C language is ANSI. > This program > compiles at my school which also uses the GNU libraries (Not > Linux). Thanks ahead of time. oem Yes, the *BSD libraries are old stuff. -- Al Longyear longyear@sii.com The above opinions do not necessarily represent those of the Management of System Integrators nor any of its subsidiaries. ------------------------------ From: hpa@freya.yggdrasil.com (H. Peter Anvin) Subject: Re: Netscape/Mosaic for ELF Date: 12 Dec 1995 07:57:09 GMT Reply-To: hpa@storm.net (H. Peter Anvin) Followup to: <4af1ui$n2n@work.smurf.noris.de> By author: smurf@work.smurf.noris.de (Matthias Urlichs) In newsgroup: comp.os.linux.development.system > > > > libc.so.4.7.5 is 624K, and libm is 109K. Netscape is 3829K. When > > programs are that size, it seems pointless to worry about a few > > hundred K for libraries. You just need the .so files, not the .sa, .a > > or .h files. > > > Netscape is that big because it's linked statically to Motif, which is a > sin in itself. :-( (Some day, there'll be a dynamically-linked Netscape, > and my Motif library will be a symlink to Lesstif. Until that day...) > > It's _another_ "few hundred K" of memory. It'll make the system another few > percent points slower. _I_hate_that_. We can all imagine what happens if > everybody thinks "these two percent won't hurt". > True, although not all of it will be in core of course. I am currently running a mixed ELF/a.out system, and yes, it does slow things down, which is unfortunate... especially since I just had to drop down from 24 MB to 16 MB RAM... of course, at work I was wrestling with Solaris not wanting to run with any speed at all with 32 MB on a SPARC 2 (48 MB was OK -- at least I think it is the CPU or data bus that's the limiting factor now). /hpa -- PGP public key available - finger hpa@terminus.storm.net "The earth is but one country, and mankind its citizens." -- Baha'u'llah I don't work for Yggdrasil, but they sponsor the linux.* hierarchy. ------------------------------ From: jrj@bu.edu (John James) Subject: y Date: 12 Dec 1995 15:35:45 GMT ------------------------------ From: Arnt Gulbrandsen Subject: Re: Linux ISO 7816 emulator (was: New Voyager) Date: 13 Dec 1995 18:19:33 +0100 rob@pe1chl.ampr.org (Rob Janssen) > In Arnt Gulbrandsen writes: > > >rob@pe1chl.ampr.org (Rob Janssen) > >> The problem is that only one of the three PC timers can generate > >> an interrupt. This is the timer currently used for the 10ms ticks. > > >It's possible to reprogram that on every interrupt; I've done it. It > >was tricky and I didn't get a solid solution. PC hardware hits again. > > Yes, it can be done... did you get reliability problems? or just > the accuracy problem? Accuracy only, as far as I could see. > >All a little bit tricky, because by the time the interrupt routine > >starts, the counter is at N-5 or N-11 or something. The number 11 > >comes to mind, but that was 1992, on a 386sx16, P90s are probably > >faster. Icky. > > The number of extra ticks depends on the interrupt latency at that > moment. [...] I know... for me it was serious enough to give up. --Arnt ------------------------------ From: mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) Crossposted-To: alt.satellite.tv.crypt Subject: Linux ISO 7816 emulator (was: New Voyager) Date: 11 Dec 1995 18:32:57 +0100 Reply-To: mskuhn@cip.informatik.uni-erlangen.de rob@pe1chl.ampr.org (Rob Janssen) writes: >Markus Kuhn writes: >>At the moment, you'll have to use lseason (a kernel module, which is >>not a very elegant, but at the moment the only practical solution). >Indeed, but it works fine. I have used it for quite some time (at the >moment is still works on 2 channels), and I think it is still a lot >better than having to dedicate a PC to run DOS and a "season" type >program. My Linux machine does a lot of things in the home, and >looking after the VideoCrypt decoder is just one of them. >It would be nice to have some realtime support in Linux, as long >as it does not influence overall performance. It is easy to implement a real-time scheduler in a way that will not affect overall performance when zero real-time processes are active. It is just one additional if () in the scheduler. >As an aside: the major nuisance in implementation of a smart card >emulator on Linux are the extra stopbits, which require a small delay >that is too short to use timer ticks and a waste to spend in usleep. >I have been thinking about tricks to do with the UART, but have not >been able to find something that can be done without hardware mods >to the interface card. Probably there should have been some or-ing >between transmit data and a handshake line, so that you could switch to >a higher baudrate, assert the handshake line, transmit a dummy >character, and wait for the next interrupt before switching back to 9600 >and sending the next real character. Yes, this is a serious problem. With all currently available blocking solutions, in the worst case, the next timer interrupt could come as late as 10 ms later. However, for the VideoCrypt protocol, you'll have to wait pretty exactly 0.5-1.5 ms between sending the bytes (i.e., the extra ~5 stop bits you mentioned). If you have a practical idea how this can be accomplished with the Linux serial driver without a busy wait sitting on gettimeofday() (that's the ugly solution I tried so far), please let me know! The best solution I can think of so far is to use an individually programmed timer interrupt. A PC has three timers and AFAIK, one of them is still unused (the NetBSD folks use it for kernel profiling, I'd prefer to spend it for real-time timing functions). We could implement the POSIX.1b itimers in a way that programs the third interrupt timer so that we get an interrupt exactly at the requested time (and not only in the classical 1/HZ s raster). This would allow to implement real-time itimers with microsecond resolution. Of course, there would have to be some kind of ordered wait queue for interrupt timer jobs so that several POSIX.1b itimers can be used simultaneously. If e.g. the POSIX.1b nanosleep() function would be implemented this way, realizing a user process VideoCrypt protocol driver under Linux should become as easy as under MS-DOS. Markus -- Markus Kuhn, Computer Science student -- University of Erlangen, Internet Mail: - Germany WWW Home: ------------------------------ From: ctkwan@cs.hku.hk (Doug Kwan ~{9XUq5B~}) Subject: Are libc functions MT-safe? Date: Fri, 8 Dec 1995 16:21:25 GMT I am writing a multi-thread application on SGI. Irix has got a very nice system call for threads called sproc. It just "forks" off a new thread in the addressing space of the parent with a newly allocated stack. Also, library functions like malloc are MT-safe. I have a Pentium at my home running Linux and I would like to move some of work from the workstation in my office to my home. I browsed through the man-pages. So I found the clone() system call which looks like sproc() in Irix but the two are exactly the same. I need to know some info about clone(). 1. Could anyone kindly tell me who is responsible for stack allocation in clone()? What happen to the stack if a thread quits. Does the OS reclaim the stack under such circumstances? 2. Are library functions like malloc MT-safe? Or do I need to use a semaphore to ensure that threads do not mess up the heap? Thanks. :) -- Doug Kwan ~{9XUq5B~} Graduate Student Department of Computer Science The University of Hong Kong ------------------------------ ** 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-System-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development.system) via: Internet: Linux-Development-System@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-System Digest ******************************