Unix Technical Digest V2 #2

[Heiby]

Unix Technical Digest       Fri, 10 May 85       Volume  2 : Issue   2

Today's Topics:
                       Can we junk umask(1,2) ?
                  CTS/RTS handshake - a hardware fix
                 Default "make" rule for RCS Checkout
                        rsh (Restricted Shell)
                  Saving Terminal modes on a pyramid
            Summary of responses to my {c,m,re}alloc query
                   System V for IBM-like mainframes
----------------------------------------------------------------------

Date: 06-May-85 14:41:11 MET (Monday)
From: seismo!mcvax!enea!sal!jf (Johan Finnved)
Subject: Can we junk umask(1,2) ?

About one year ago I came across some papers on BSD describing their
protection sceme where a process have belong to several groups
when it comes to accessing files, and files are born with a
group id taken from the directory where it was first created rather
than from the process effective gid.

I thought this was a very good idea and iimidiately hacked it into
our XENIX 2.3 kernel. - It wasn't hard at all.

Now to the point:
Could we use the same sceme for protection codes that is:
- mkdir(1) would create directories with identical privileges as "newdir/.."
- create(2) would mask the write bits with corresponding directory write bits
  and read and execute bits would be masked with corresponding directory
  read bits.
  (not directory execute bits since they have a completely different meaning).
This default may be correct more often than the static umask value.
(It may cost less anger when people update a common project with umask=027)

What do people think about this.

			Johan Finnved @ Objecta, Sweden

------------------------------

Date: Fri, 3 May 85 23:13:31 edt
From: <ihnp4!philabs!wu1!rf>
Subject: CTS/RTS handshake - a hardware fix

Given that there appears to be no easy software solution to Howard Shaw's
CTS/RTS problem, perhaps a hardware solution is appropriate.  Black Box (PO
Box 12800, Pittsburgh, PA 15241, telephone 412-746-5530) part number J-CMF10
($600) described as an "X-ON/X-OFF Flow Control Converter" should do the job.

For those of you who aren't familiar with Black Box products, I recommend
you request one of their catalogs.  They offer a large number of
communications products, many of which are quite valuable to managers of
computer centers.

		Randolph Fritz
UUCPnet:	{ihnp4,decvax}!philabs!wu1!rf
Easylink:	62905318

------------------------------

Date: Wed, 8 May 85 22:14:03 pdt
From: sdcrdcf!sdcsvax!hidley (Greg Hidley)
Subject: Default "make" rule for RCS Checkout

The following works fine to get "make" to retrieve source code
which has been checked in with RCS. The DEFAULT rule is what gets
used when all other suffix searches and transformation rules fail:

	.DEFAULT:
		co -q $<
		${CC} $(CFLAGS) -c $*.c
		rm -f $*.c

Greg Hidley, sdcsvax
...!ucbvax!sdcsvax!hidley
  or
hidley at UCSD

------------------------------

Date: Mon, 6 May 85 13:06:59 EDT
From: ihnp4!seismo!Sienkiew at UDel-Huey.ARPA
Subject: rsh (Restricted Shell)

A word of warning to those who might think that rsh has some usefulness.
rsh allows you to execute any command in /bin or /usr/bin.  Among these are
sh, csh, ed, and vi, each of which is a convienient way to get to an
unrestricted shell.  DON'T USE RSH AS A SECURITY SCHEME!!!

example:
your shell is rsh
$ cd /tmp
cd: restricted
$ csh
% cd /tmp
% 

If you have source, you should probably hack this stuff out of your shell.
At least scripts that begin with r will still work...
	
		Mark.

[Ed note:  While rsh does have some significant security problems, the one
mentioned here can beovercome fairly well by changing the PATH environment
variable to one which contains only those programs deemed "safe", then making
PATH and SHELL environment variables read-only.  Any discussion of rsh
security will be held by me for a few weeks so that it doesn't dribble out
over such a protracted period that everyone gets sick of it.  RWH.]

------------------------------

Date: Thu, 9 May 85 11:06:07 edt
From: Arnold Robbins <gatech!arnold>
Subject: Saving Terminal modes on a pyramid

	I have been doing some work with the Bourne shell, and have
added code for the pyramid which makes 'att', 'ucb', and 'universe' commands
built in to the shell.  I have not implemented the -t option, because
I don't know how.

	My question is, how does the -t option of /bin/att and /bin/ucb
work?  The manual is pretty terse, only stating that the terminal state is
saved and then restored, but I am not sure how to go about doing that, since
OSx somehow keeps both the att and ucb terminal control structures in one
big structure someplace.  How do I go about saving and restoring all this
info, preferably without a lot of work?

	We do not have source for OSx, so I can't go look at the source
for att and ucb to figure it out. (I moved the shell from a vax, which we
do have source licensed.)  It is probably not a good idea anyway, since I
want to post the changes, and Pyramid might not like it if I borrowed their
code! :-)

	Any and all help would be appreciated.  I have made a bunch of other
mods to the shell, and will be posting them to Usenet net.sources (or maybe
mod.sources), as soon as one or two more things are finished.

Thanks,

Arnold Robbins
CSNET:	arnold at gatech	ARPA:	arnold%gatech.csnet at csnet-relay.arpa
UUCP:	{ akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold

------------------------------

Date: Tue, 7 May 85 21:41:43 edt
From: allegra!phri!roy (Roy Smith)
Subject: Summary of responses to my {c,m,re}alloc query

	The general opinion is that on any post V6 system, you can mix
calls to {c,m,re}alloc with impunity.  Darin Johnson <ee163acp at sdcc13>,
however, writes the following in <213 at sdcc13.UUCP> posted to net.unix:

	On the pyramid OSx it seems that if free() is called with
	something calloc()'d it doesn't do what is expected.  I try
	to keep this consistent, but I called free() instead of
	cfree() in one place, and then later when calling malloc,
	it returned something still in use.  Replacing this free()
	with cfree() immediately solved the problem.

	As I see it, it's OK to use calloc/cfree in one part of your
program and malloc/free in another as long as you cfree the blocks you
calloc'ed and free the blocks you malloc'ed.  Any OSx wizards out there
care to comment?

allegra!phri!roy (Roy Smith)
System Administrator, Public Health Research Institute

------------------------------

Date: Fri, 3 May 85 17:20:14 bst
From: Robert Stroud <garfield!mcvax!ukc!cheviot!robert>
Subject: System V for IBM-like mainframes

Has anybody had any experience of Unix on an IBM-like mainframe?
We are particularly interested in IX/370 on an IBM, and UTS/V
on an Amdahl. Does anybody know of any performance or reliability
comparisons that have been made?

Please mail me, and I'll summarise to the net.  Thank you.

Robert J Stroud, Computing Laboratory, University of Newcastle upon Tyne.
UUCP ...!ukc!cheviot!robert
ARPA robert%cheviot%newcastle.mailnet at mit-multics.ARPA
JANET robert at uk.ac.newcastle.cheviot (or uk.ac.neda).

------------------------------

End of Unix Technical Digest
******************************
-- 
Ronald W. Heiby / netnews at wnuxb.UUCP | unix-request at cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL  (CU-D21)