mail to xenurus.gould.com
postmaster at urbana.mcd.mot.com
postmaster at urbana.mcd.mot.com
Wed Jul 12 00:58:41 AEST 1989
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 at urbana.mcd.mot.com.
thank you for your cooperation,
postmaster at 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) <Unix-Wizards-Request at BRL.MIL>
To: UNIX-WIZARDS at BRL.MIL
Reply-To: UNIX-WIZARDS at BRL.MIL
Subject: UNIX-WIZARDS Digest V7#123
Message-Id: <8907080245.aa01145 at 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 <dhesi at bsu-cs.bsu.edu>
Subject: Re: at files and permissions
Date: 6 Jul 89 04:52:39 GMT
To: unix-wizards at 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 at ficc.uu.net> peter at 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 <dhesi at bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
-----------------------------
From: Rahul Dhesi <dhesi at bsu-cs.bsu.edu>
Subject: Re: at files and permissions
Date: 7 Jul 89 00:54:13 GMT
To: unix-wizards at sem.brl.mil
In article <228 at arnor.UUCP> uri at 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 <dhesi at bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
-----------------------------
From: Guy Harris <guy at auspex.auspex.com>
Subject: Re: at files and permissions
Date: 7 Jul 89 06:36:00 GMT
To: unix-wizards at 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 <urban at randvax.uucp>
Subject: Re: chown (was: at files and permissions)
Date: 6 Jul 89 15:18:39 GMT
To: unix-wizards at sem.brl.mil
In article <22969 at iuvax.cs.indiana.edu> bobmon at 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 at rand.ORG
-----------------------------
From: "Clifford C. Skolnick" <ccs at lazlo.uucp>
Subject: Re: What kinds of things would you want in the GNU OS?
Date: 7 Jul 89 03:30:04 GMT
To: unix-wizards at sem.brl.mil
In article <214 at tnl.UUCP> norstar at tnl.UUCP (Daniel Ray) writes:
|In article <8906272337.AA24210 at cscwam.UMD.EDU>, stripes at 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 at lazlo.UUCP
-----------------------------
From: Craig Bruce <craigb at hpqtdla.hp.com>
Subject: Re: local test
Date: 7 Jul 89 07:10:57 GMT
To: unix-wizards at 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 <jos at idca.tds.philips.nl>
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 at sem.brl.mil
In article <656 at wrs.wrs.com> hwajin at 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 at idca.tds.philips.nl ######
-- ###### ###### UUCP ...!mcvax!philapd!jos ######
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: SVR4 (was: Re: at files and permissions)
Date: 7 Jul 89 13:48:23 GMT
To: unix-wizards at sem.brl.mil
In article <4896 at ficc.uu.net> peter at 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 <jos at idca.tds.philips.nl>
Subject: ftruncate(2) for System V.3.2 needed
Date: 7 Jul 89 14:07:29 GMT
To: unix-wizards at 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 at idca.tds.philips.nl ######
-- ###### ###### UUCP ...!mcvax!philapd!jos ######
-----------------------------
From: "Anoop R. Hegde" <anoop at ECE.ORST.EDU>
Subject: help needed on ethernet packet access on BSD4.3unix
Date: 7 Jul 89 17:37:36 GMT
Sender: usenet at CS.ORST.EDU
To: unix-wizards at 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 at guille.ece.orst.edu
Dept. of ECE, UUCP : tektronix!orstcs!hegdea
Oregon State University or : hplabs!hp-pcd!orstcs!hegdea
--------------------------------------------------------------------------
-----------------------------
From: "Kevin L. Allred" <allred at ut-emx.uucp>
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 at 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 at emx.cc.utexas.edu
allred at ut-emx.UUCP
-----------------------------
End of UNIX-WIZARDS Digest
**************************
---------- end of forwarded message
More information about the Comp.unix.wizards
mailing list