From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sun, 17 Oct 93 21:13:10 EDT Subject: Linux-Development Digest #170 Linux-Development Digest #170, Volume #1 Sun, 17 Oct 93 21:13:10 EDT Contents: linux & 3c501 ? experiences ? (Russell Nelson) Re: Linux-IPC-Performance (Gareth Bult) >Re: WARNING: compressed archives don't (Gareth Bult) Re: set*id (Theodore Ts'o) Re: Can't install Yggdrasil - a workaround found. (Theodore Ts'o) QIC-150 Drivers... (Gareth Bult) Re: set*id (Fergus James HENDERSON) Re: Packet Fragmentation = ? (Matthew Dillon) Re: Scanner-Driver (Kai Kretschmann) Re: Linux System Administration Tools (al-b@minster.york.ac.uk) Re: QIC-150 Drivers... (Brandon S. Allbery) [Q] CH-101G ISA IDE Controller w/ Linux (Jouni A Kosonen) Re: Linux Slowly Dying Off? + Lets make a game for Linux (Rich Braun) /dev not needed? (Stephen Harris) Re: QIC-150 Drivers... (Clayton Haapala) Re: QIC-150 Drivers... (BARRY TITMARSH) ---------------------------------------------------------------------------- From: nelson@crynwr.com (Russell Nelson) Subject: linux & 3c501 ? experiences ? Date: 14 Oct 93 02:52:59 GMT In article <1993Sep25.061144.1382@truffula.sj.ca.us> cls@truffula.sj.ca.us writes: In article <1993Sep24.023318.23188@super.org> becker@super.org (Donald J. Becker) writes: >OK, there seems to be a number of 3c501 fans out there, and a few of them >insist on telling my why it isn't so bad. They are wrong [...] I'm speaking only for myself here, of course, but I believe 3Com advises against installing a 3C501 in a new system, mostly for the same reasons Donald has discussed. You probably won't be happy with the 3C501 in your Linux box. Yup. That would be like using a CGA for your video board. -russ What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do. ------------------------------ From: gareth@gblinux.demon.co.uk (Gareth Bult) Subject: Re: Linux-IPC-Performance Date: Sat, 16 Oct 1993 17:55:42 GMT Haven't tried it (but I will), but IPC was a fairly late addition wasn't it? It looks like a bolt-on job. I have a couple of Unix books with source.. looks like it's fairly easy to implement... you could always try your own version... ;) ------------------------------ From: gareth@gblinux.demon.co.uk (Gareth Bult) Subject: >Re: WARNING: compressed archives don't Date: Sun, 17 Oct 1993 11:30:14 GMT No, it backs up fine. It's the restore that don't work. ------------------------------ From: tytso@athena.mit.edu (Theodore Ts'o) Subject: Re: set*id Date: 17 Oct 1993 10:03:21 -0400 Reply-To: tytso@athena.mit.edu (Theodore Ts'o) From: ig25@fg30.rz.uni-karlsruhe.de (Thomas Koenig) Date: 14 Oct 1993 10:20:24 GMT A suid root program could set its effective and real userid to the real user's and keep the saved userid 0. This would make it possible to retain the privileges later (because setresuid still works) but will allow a safe exec(), either voluntarily or involuntarily via the 'smashed stack' scenario. Errors in memory allocation are very common; it is not unlikely that a knowledgable cracker with access to the source can come up with a way to make the program exec() his own by exploiting this kind of bug. I don't want to worry about security in a part of a suid root program where I'm supposed to have given up all privileges. Ah, now I see what you're trying to do; yup, under those circumstances setresuid() is a little bit more secure. Note however that errors in memory allocation that can result in the "smashed stack" scenario are actually relatively infrequent. In fact, the problem isn't memory allocation per se, but an array overrun for an array that has been allocated as an automatic. Most memory allocation errors will much more likely result in core dumps than an attack actually managing to get code instructions stuffed in by the attacker to actually run. The other thing which confused me is that the finger attack wouldn't have been helped by setresuid() in any case, since fingerd isn't a setuid program. Inetd was running as root, and depending on how inetd.conf was set up, fingerd was being exec'ed either as root or as daemon or as 'nobody'. But as it turns out, the Internet Virus didn't need root priviletges during the fingerd attack --- it was enough for it to get access with an unprivileged shell. MORAL: Even if you had setresuid(), you can't ignore issues of array overrun of automatic variables. Never using gets(), under any circumstances, is probably one of the most effective ways to ensure this. :-) In any case, it certainly wouldn't hurt to implement setresuid() in the Linux kernel; although for backwards compatibility, we'd obviously have to keep setuid() and setreuid() in the kernel. Hmm... how about another idea, also stolen from HP, to reduce the need for suid root programs? Via the setprivgrp(2) call, the superuser can give the right to make certain system calls to special groups. Hmm... we should take a look at how POSIX.6 dealt with this. They've spec'ed out a POSIX extention which has the rough functionality of setprivgrp() (i.e., VMS-style privilege bits) although I believe they did it on a smaller granularity --- i.e., either per-process or per-uid, I don't remember which. - Ted ------------------------------ From: tytso@athena.mit.edu (Theodore Ts'o) Subject: Re: Can't install Yggdrasil - a workaround found. Date: 17 Oct 1993 10:08:25 -0400 Reply-To: tytso@athena.mit.edu (Theodore Ts'o) From: kevin@frobozz.sccsi.com (Kevin Brown) Date: Sat, 16 Oct 1993 07:24:24 GMT An interesting thing I've noticed about the behavior of the kernel with respect to my MO drive (and this may be generalizable to all removable media drives) is that the kernel doesn't reliably recognize that a disk change has been performed. The only way I can guarantee it gets it right is by removing the media, doing something to access the drive while there's no media in the drive, inserting the new media, and then doing something to access the drive again. The kernel can certainly determine this for (non-SCSI) floppy drives; I don't know if the problem is that your MO drive isn't sending the disk change event to the SCSI adaptor, or that the SCSI code doesn't deal with disk changes, and so isn't passing it up to the buffer cache layer. I haven't had a chance to look at the SCSI code myself. However, if you're looking for a way to flush your buffer cache, there's a simple little program to do this. It's part of my e2fsck distribution, since I want to flush my buffer cache before timing how fast e2fsck runs. It's a small enough program that I'll just append it at the end of this message. - Ted P.S. Note that it has to run as root, or be setuid. /* * flushb.c --- This routine flushes the disk buffers for a disk */ #include #include #include #include #include #include #include char *progname; void usage() { fprintf(stderr, "Usage: %s disk\n", progname); exit(1); } int main(int argc, char **argv) { int fd; progname = argv[0]; if (argc != 2) usage(); fd = open(argv[1], O_RDONLY, 0); if (fd < 0) { perror("open"); exit(1); } /* * Note: to reread the partition table, use the ioctl * BLKRRPART instead of BLKFSLBUF. */ if (ioctl(fd, BLKFLSBUF, 0) < 0) { perror("ioctl"); exit(1); } return 0; } ------------------------------ From: gareth@gblinux.demon.co.uk (Gareth Bult) Subject: QIC-150 Drivers... Date: Sun, 17 Oct 1993 17:42:22 GMT Is anybody working in a QIC-150 driver for Linux? OR is there one? ------------------------------ From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) Subject: Re: set*id Date: Sun, 17 Oct 1993 17:25:44 GMT ig25@fg30.rz.uni-karlsruhe.de (Thomas Koenig) writes: >Hmm... how about another idea, also stolen from HP, to reduce the need >for suid root programs? > >Via the setprivgrp(2) call, the superuser can give the right to >make certain system calls to special groups. > >For exaple, a call setprivgrp(10, PRIV_CHOWN) will give the group 10 >(usually wheel) the right to chown files; a program which does this does >not need to be suid root; it could be made setgid wheel instead. That >is a Good Thing (TM) when you look, for example, at xterm, which is a) a >complicated mess and b) is suid root in order to chown the pty's, with >known and serious problems. Sounds like an excellent idea to me. -- Fergus Henderson fjh@munta.cs.mu.OZ.AU ------------------------------ From: dillon@moonshot.west.oic.com (Matthew Dillon) Subject: Re: Packet Fragmentation = ? Date: 17 Oct 1993 10:17:07 -0700 In article <750812933.F00001@leotech.mv.com> epoole@leotech.mv.com (Eric Poole) writes: :Can someone please tell me the current state of the IP :packet fragmentation support? : :The NET-2-HOWTO indicates that frag/defrag should be :implemented in NET-2e; I'm not even sure at this point where :the NET-2(suffix) is but believe we are past 2e (right?); :did frag/defrag make it in? : :Thanks much; if you wish to reply via e-mail :(epoole@leotech.mv.com) I'll summarize. : : . . . . . ep : : * Origin: NETIS Public Access Internet (603)432-2517 (1:132/189) Yes, fragmentation is implemented. The net-2e stuff is currently in a very alpha beta, not ready for general consumption yet but getting closer thanks to the hard work of Fred. -Matt Matthew Dillon dillon@moonshot.west.oic.com 1005 Apollo Way dillon@overload.berkeley.ca.us Incline Village, NV. 89451 ham: KC6LVW (no mail drop) USA Sandel-Avery Engineering (702)831-8000 [always include a portion of the original email in any response!] ------------------------------ From: kai@fix.kmk.rhein-main.de (Kai Kretschmann) Subject: Re: Scanner-Driver Date: Sat, 16 Oct 1993 10:28:37 GMT Rick (pclink@qus102.qld.tne.oz.au) wrote: : Andreas_Matthias@p43.rollo.central.de (Andreas Matthias) writes: : >announce that I began writing one. It will be a driver for Logitech ScanMan : I have a driver for GS4500 type scanners (ie handhelds). One should classify how many hardware types of scanners are in the market. I think some vendors sell the same hardware with different or even the same outfit. I myself would like to use a Mustek 800, I think we have three types of handscanners: 1) Scanman 2) GS4500 3) Marstek/Mustek There might be some common features so we should merge all existing drivers, shake a lot, and lets see if we get a universal driver for them. PS: If we get the drivers working, how are the used? Under X? And what software gets the data? Or does the driver only create an image file for further convertion using PBM-Tools? -- Kai Kretschmann, >>> FidoNet: 2:248/312, 21:100/5729, 16:100/6006 <<< >>> Internet: kai@fix.kmk.rhein-main.de <<< >>> FAX/BBS: +49-6172-305379 <<< ------------------------------ From: al-b@minster.york.ac.uk Subject: Re: Linux System Administration Tools Date: 15 Oct 1993 12:23:28 GMT In article <1993Oct12.163429.656@cathy.ijs.si> Andrej.Bauer@ijs.si (Andrej Bauer) writes: >Dear Developers, > >is there anybody working on System Administration Tools for Linux? >I think it would be nice to have an intelligent and easy-to-use >program for Linux's System Administration (something like SAM for HP-UX, >only more intelligent -- it should be very very smart). > >If anybody knows of a project or people who are working on this, >please tell me. If such a project does not exist yet, anybody >who is interested is welcome to contact me. > >Andrej > >------------------- >Andrej.Bauer@IJS.si >------------------- I think I had heard something about a port of SMIT sometime in spring (ie. before Easter). Anyone know anything about that? SMIT is the System Management Interface Tool used on IBM RS/6000 machines. I've never actually used it, because I'm not root on our IBM :-( Andrew. ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: QIC-150 Drivers... Date: Sun, 17 Oct 1993 21:03:16 GMT In article <499@gblinux.demon.co.uk> gareth@gblinux.demon.co.uk (Gareth Bult) writes: >Is anybody working in a QIC-150 driver for Linux? QIC-150 is a tape format, not a device specification. What is the QIC number for the device interface? Most QIC-150 format tape drives use either QIC-02/QIC-36 (not interchangeable, but many QIC-36 controllers use QIC-02 commands) or SCSI. SCSI is in the stock kernel, whereas I believe QIC-02 is still an add-on. Look for the "tpqic02" package on tsx-11 or sunsite if your tape drive uses QIC-02 or QIC-36. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: jok@snakemail.hut.fi (Jouni A Kosonen) Subject: [Q] CH-101G ISA IDE Controller w/ Linux Date: 17 Oct 93 21:47:08 GMT This might actually belong in col.help, but there is a development aspect too. I've just installed Linux a couple of days ago, and everything's working flawlessy. I used Slackware's 1.04-release (0.99pl13), not a bad release at all. The problem: My HD-controller is CH-101G ISA IDE with 4Mb of RAM. The caching works OK, but the card also supports two additional drives. This doesn't work w/ Linux. The card came with a driver for DOS, but no other drivers were included. Curiously, there seems to be no reference to the manufacturer of the board anywhere in the documentation, the controller BIOS or the driver. There is a fragment - not displayed, though - in the driver saying 'Designed by: Eric LO' and 23 spaces... So, I don't think I'll be able to ask them for a driver. I've been through the DOS driver w/ Sourcer, but I just can't figure out what it does to access the drives 2/3. All port access is to 01F0-01F7 and 03F6, IRQ14, as per drives 0/1, so there must be some rather devious way to tell the card which drive to access. So, is there anyone else with the same / a similar problem? Any solutions yet? Any interest in one? If I find a way to make Linux see those additional drives, would there be enough generality to warrant a posted kernel patch? Thanks for your interest, or if there is none, sorry for wasting your time Jouni Kosonen These should work: jok@niksula.cs.hut.fi jok@niksula.hut.fi jok@beta.hut.fi ------------------------------ Crossposted-To: comp.os.linux.misc From: richb@pioneer.ci.net (Rich Braun) Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: Sun, 17 Oct 1993 21:17:33 GMT In article <29qlks$8d6@news.u.washington.edu>, Tim Smith wrote: >I'm confused. Won't SCO do all the stuff you were doing with Linux? >Why is it just sitting on the shelf there? SCO can do it but not anywhere near as gracefully as Linux. The last time I used SCO, its mountable DOS filesystem code was *real* slow, and the doscp utility was very cumbersome (can't take wildcards, etc). With Linux you just issue a 'mount -t msdos /dev/fd0H1440 /mnt' command and it performs every bit as fast as the hardware can handle (when *will* the 1.44M floppy finally fade away?). SysVr4 isn't even as nice as SCO. Linux wins hands-down over every commercial enviroment for ease of use in its DOS integration tools, in my book. -rich -- Isn't it time for a new ____ New England Community Internet .signature? \ / Home: richb@pioneer.ci.net \/ Work: braun@leds.enet.dec.com NECI: info@pioneer.ci.net ------------------------------ From: sweh.womble@spuddy.UUCP (Stephen Harris) Subject: /dev not needed? Date: Sun, 17 Oct 93 22:51:17 GMT Was in the shower and had this strange idea: /dev isn't really needed anymore. Most (all?) of the functionality it provides could be done using extensions to /proc filesystem. Basically, when a driver registers itself, it also registers a list of filename/major/minor devices that get stored in /proc/dev/ I can see the following advantages: 1) a standardised set of device names. Are inet devices in /dev/ or /dev/inet/ or whatever. What ARE serial device names? And so on. 2) Would be easy to see what the kernel has recognised about your hardware (if there is no /proc/dev/sda then you haven't got SCSI disks etc) I can see the following disadvantages: 1) kernel bloat. kernel would have to store filenames 2) harder to customize. Would either need clever code so that a mknod in /proc/dev (or symlinks?) would allow people to change device names (eg make "mouse" and "modem" point to the serial ports. make "sr0" a standard CD name) or a program that can add device name "aliases". Or something. Disadvantage (2) is solvable (even if bootup means cp -av /proc/dev /). Comments? Stephen Harris sweh.womble@spuddy.uucp ...!uknet!axion!spuddy!sweh.womble * Meow! Call Spuddy the Cat for Usenet access in the UK. Call 0203 364436 * ------------------------------ From: clay@haapi.mn.org (Clayton Haapala) Subject: Re: QIC-150 Drivers... Date: Sun, 17 Oct 1993 20:52:17 GMT In article <499@gblinux.demon.co.uk> gareth@gblinux.demon.co.uk (Gareth Bult) writes: >Is anybody working in a QIC-150 driver for Linux? >OR is there one? > > Won't the QIC-02 driver in the pl12 and pl13 kernels do it for you? You will have to edit the tpqic02.h file to pick the controller type (Wangtek, Archive) and the I/O ports and IRQ. Works well. -- Clay Haapala "Well, there was the process of sitting around clay@haapi.mn.org and wishing I had more computer stuff." -- Dilbert ------------------------------ Date: Mon, 18 Oct 1993 00:54:02 CET From: BARRY TITMARSH Subject: Re: QIC-150 Drivers... Wrong... QIC02 is now stock in the kernel and will work with qic 11 24 120 15 250 550 and some of the big drive formats. just a matter of selecting the minor number on the /dev/tape major being 12.. Barry. ------------------------------ ** 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 ******************************