Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!xadmx!postmaster@urbana.mcd.mot.com From: postmaster@urbana.mcd.mot.com Newsgroups: comp.unix.wizards Subject: mail to xenurus.gould.com Message-ID: <20211@adm.BRL.MIL> Date: 11 Jul 89 14:58:41 GMT Sender: news@adm.BRL.MIL Lines: 353 The enclosed mail message was addressed to a system which is no longer in service. We have attempted to forward your mail to the correct recipient(s). If this is not possible, you will recieve additional mail at the time of failure. In the future, please use the system name "urbana.mcd.mot.com" instead. Please correct any mailing lists or alias files that may reference any of the following obsolete system names: xenurus.gould.com fang.gould.com fang.urbana.gould.com vger.urbana.gould.com ccvaxa.gould.com ccvaxa.urbana.gould.com burt.urbana.gould.com mycroft.urbana.gould.com If you have any further problems or questions about mail to this site, please contact postmaster@urbana.mcd.mot.com. thank you for your cooperation, postmaster@urbana.mcd.mot.com Motorola Microcomputer Division, Urbana Design Center ---------- text of forwarded message: Received: from sem.brl.mil by placebo (5.61/1.34) id AA04262; Mon, 10 Jul 89 21:30:24 -0500 Received: from SEM.BRL.MIL by SEM.brl.MIL id aa01188; 8 Jul 89 2:57 EDT Received: from sem.brl.mil by SEM.BRL.MIL id aa01145; 8 Jul 89 2:45 EDT Date: Sat, 08 Jul 89 02:45:19 EST From: The Moderator (Mike Muuss) To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V7#123 Message-Id: <8907080245.aa01145@SEM.BRL.MIL> UNIX-WIZARDS Digest Sat, 08 Jul 1989 V7#123 Today's Topics: Re: at files and permissions Re: chown (was: at files and permissions) Re: What kinds of things would you want in the GNU OS? Re: local test Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP Re: SVR4 (was: Re: at files and permissions) ftruncate(2) for System V.3.2 needed help needed on ethernet packet access on BSD4.3unix scsi rll trade off questions? ----------------------------------------------------------------- From: Rahul Dhesi Subject: Re: at files and permissions Date: 6 Jul 89 04:52:39 GMT To: unix-wizards@sem.brl.mil An AT&T salesman earnestly told me that System V Release 3 does have a disk quota mechanism. I told him this was news to me. What this has to do with the following is left as an exercise for the reader. I said: ...BSD allows only root to change file ownership. In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: I certainly hope that V.4 doesn't have this *bogus* restriction. My response: I doubt that it will need to. -- Rahul Dhesi UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi ----------------------------- From: Rahul Dhesi Subject: Re: at files and permissions Date: 7 Jul 89 00:54:13 GMT To: unix-wizards@sem.brl.mil In article <228@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: [ objecting to my recommendation "when you discuss a security problem that is specific to System V, please be sure to say so clearly, else you may confuse naive users." ] >First of all, not everybody familiar with System V, knows exactly which >features of BSD (and what version!) it has or has not. So, for example, >I didn't know that you can do "chown" only being root... The problem is easily solved. Don't say (or even imply) "UNIX" at all unless you are sure you are making a general statement. Just mention specifically what operating system and revision level you are discussing (e.g. "System V Release 3" or "4.3BSD"). -- Rahul Dhesi UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi ----------------------------- From: Guy Harris Subject: Re: at files and permissions Date: 7 Jul 89 06:36:00 GMT To: unix-wizards@sem.brl.mil > 2) BSD *does* allow you to give files away. No, it doesn't - not vanilla 4.xBSD, anyway; you have to be root to change the ownership of a file. It may allow you to make some limited changes to the *group* IDs of files you own, but that's a different matter. >In SVR3, there's no specific utility to run the "at" jobs, they seem to >be simply shovelled into cron. Yup, "cron" runs 'em both, and has since S5R2. ----------------------------- From: Mike Urban Subject: Re: chown (was: at files and permissions) Date: 6 Jul 89 15:18:39 GMT To: unix-wizards@sem.brl.mil In article <22969@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >->>... BSD allows only root to change file ownership. (bogus?) >- >There are also many potential problems from hostile users (generally >undergraduates) --- consuming someone else's quota can break their >running program, make them miss an assignment deadline, etc. Putting >obscene or incriminating material in someone else's file system and then >"turning them in" can do some real *major* damage. > There are also many installations that attempt to do cost recovery (or some bureaucratic imitation thereof) by charging users for disk space. Allowing users to give away their large and expensive files to other accounts complicates matters considerably. Not knowing about SysV's ability to give away files can lead to unpleasant surprises on some machines when creating a directory using tar and discovering that the resulting files belong to someone else. -- Mike Urban urban@rand.ORG ----------------------------- From: "Clifford C. Skolnick" Subject: Re: What kinds of things would you want in the GNU OS? Date: 7 Jul 89 03:30:04 GMT To: unix-wizards@sem.brl.mil In article <214@tnl.UUCP> norstar@tnl.UUCP (Daniel Ray) writes: |In article <8906272337.AA24210@cscwam.UMD.EDU>, stripes@wam.UMD.EDU writes: |> ... |> I would like to see a few extra protection bits in the new Kernal. A bit |> for append-only (the kernal fseeks to the end of the file before each write). | | 1. A new (or new use of a) directory permission bit, such as using SUID/SGID |or something new, would designate the dir as "append only except edit in |single user mode". This would apply to root as well. So, audit trails and |logfiles could not be modified except when the machine was brought down to |single user mode at the local console. Files in the dir could be appended |to, however, if the mode on the file permitted writes. Existing data could |not be modified by anyone in multiuser mode. If I was the superuser, I could just wipe out the raw disk devices. The only way this will work is to use an on-line printer. The whole concept of a super-user is the problem. I wish I had a better solution to offer, but... Cliff -- "I'd rather stay here with all the madmen, than perish with the sad man roaming free" -- David Bowie "Life is a test, only a test. If it was real, you would have been given much better instructions." Clifford C. Skolnick / (716)427-8046 / ccs@lazlo.UUCP ----------------------------- From: Craig Bruce Subject: Re: local test Date: 7 Jul 89 07:10:57 GMT To: unix-wizards@sem.brl.mil local test ???? I don't know what you define the term 'local' as, but I thought you'd like to know that your message reached me here in South Queensferry (near Edinburgh). Yours Helpfully, Craig. ----------------------------- From: Jos Vos Subject: Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP Date: 7 Jul 89 10:07:37 GMT Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3 To: unix-wizards@sem.brl.mil In article <656@wrs.wrs.com> hwajin@wrs.UUCP (Hwajin Bae) writes: >HDB UUCP that comes with AT&T V.3.2 UNIX includes support for TLI, TLIS, and >socket interfaces to TCP/IP connections. Using existing TLIS (TLI STREAMS >Based) code, all you need is to set up listener service database to invoke >uucico when a request comes in from a remote TCP/IP host. This is only useful >if you have another machine with TCP/IP, TLI, and equivalent UUCP. The socket code is between BSD42 (or whatever) #ifdef's. Isn't it? I know about the TCP/IP via TLI(S), but I need to be able to talk to BSD systems too. >Porting BSD 4.3 UUCP daemon has already been done several times for different >incarnations of TCP/IP implementations for system V Unix's. Unfortunately >none of them are "free" that I know of. I only need the patches, I have the BSD4.3 uucpd source... -- -- ###### Jos Vos ###### Internet jos@idca.tds.philips.nl ###### -- ###### ###### UUCP ...!mcvax!philapd!jos ###### ----------------------------- From: Doug Gwyn Subject: Re: SVR4 (was: Re: at files and permissions) Date: 7 Jul 89 13:48:23 GMT To: unix-wizards@sem.brl.mil In article <4896@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Does anyone here really know what sort of crud V.4 (not V.3) is going to >have in it? Streams *and* sockets, or so I hear... AT&T presented an overview of SVR4 at a BOF session at the Baltimore USENIX. Therefore lots of people presumably now know what SVR4 will contain and more or less how it's implemented. Sockets are emulated; STREAMS is the basic kernel mechanism. ----------------------------- From: Jos Vos Subject: ftruncate(2) for System V.3.2 needed Date: 7 Jul 89 14:07:29 GMT To: unix-wizards@sem.brl.mil I need the ftruncate(2) function from BSD4.3 UNIX on System V.3.2. For non-BSD-manual-owners, here's the description of ftruncate(2): * ftruncate (fd, length) * int fd; * long length; * * Ftruncate causes the file referenced by fd (a file descriptor of an * file open for writing) to be truncated to at most length bytes in size. * If the file previously was larger than the size, the extra data is lost. Hint: I do *not* know the filename of the open file, of course :-) Because I don't even know if there exists a solution, also a *proof* :-) that no solution exists will be very helpfull to me (than I can start rewriting the code around ftruncate() in my application :-( ). -- -- ###### Jos Vos ###### Internet jos@idca.tds.philips.nl ###### -- ###### ###### UUCP ...!mcvax!philapd!jos ###### ----------------------------- From: "Anoop R. Hegde" Subject: help needed on ethernet packet access on BSD4.3unix Date: 7 Jul 89 17:37:36 GMT Sender: usenet@CS.ORST.EDU To: unix-wizards@sem.brl.mil ( My apologies if this posting is not very relevant to this newsgroup, but i am sure, some of you have worked on a new protocol implementation) We have a MicroVax II running BSD4.3 UNIX. I am trying to develope a new protocol parallel to IP, to be used in the local ethernet environment. ( to be specific, i would like to write programs that can receive an ethernet packet carrying an experimental 'type' field, so that I can set up communication between this machine and any other machine connected to the same ethernet) Obviously, this can't be done using sockets, (even raw) as, they don't allow access below IP level. I would be very much thankful if someone can provide me with some more info. on this matter, or atleast a pointer to pursue. ( we have the kernel source code, and it would be of much help if i know where is packet demultiplexing done and which files to look into, etc. ) -------------------------------------------------------------------------- Anoop R. Hegde internet: anoop@guille.ece.orst.edu Dept. of ECE, UUCP : tektronix!orstcs!hegdea Oregon State University or : hplabs!hp-pcd!orstcs!hegdea -------------------------------------------------------------------------- ----------------------------- From: "Kevin L. Allred" Subject: scsi rll trade off questions? Date: 7 Jul 89 21:37:43 GMT Keywords: scsi rll hard disk compatability Posted: Fri Jul 7 16:37:43 1989 To: unix-wizards@sem.brl.mil I'm putting together a low end workstation for my personal use at home. It will have a 386SX, 4MB memory and monochrome VGA graphics. Initially I plan to just run MSDOS, but soon I would like to run UNIX. I currently am considering hard drives in the range of 65 to 80 MB. I was only considering an RLL drive with 1:1 interleve controller until I had pointed out to me that Segate has recently started marketing a low cost SCSI addaptor (ST01 and ST02) suitable for use with its ST296N 80MB hard disk. This combination reportedly offeres about 750 KB/sec transfer rate, which is comparable to the 1:1 interleve RLL transfer rate, and it is more cost effective. Apparently the SCSI addaptor works fine under DOS, but I have already had related to me that it probably won't work with UNIX because of lack of drivers (I heard that was a problem common to most SCSI boards even the expensive intelligent ones like the WD7000). Are the various UNIX vendors developing drivers, so that I don't need to worry about this, or should I stick with the RLL controller and disks? -- Kevin Allred allred@emx.cc.utexas.edu allred@ut-emx.UUCP ----------------------------- End of UNIX-WIZARDS Digest ************************** ---------- end of forwarded message