Unix Technical Digest V1 #55

[Heiby]

Unix Technical Digest       Wed,  1 May 85       Volume  1 : Issue  55

Today's Topics:
               File system limit in 4.2 BSD (followup)
                 malloc/calloc and portable software?
               Safe version of system(3) call. (2 msgs)
                SVR2 termio(7) common misunderstanding
                    Which IPC for passing control?
----------------------------------------------------------------------

Date: 29 Apr 85 13:15:12 GMT
From: dhb at rayssd.UUCP
Subject: File system limit in 4.2 BSD (followup)

Thanks to all who replied to my request for a way to mount more than
fifteen file systems in 4.2 BSD.  There is indeed something besides
the size of the fields in the core map that needs to be changed and
it CAN cause weird swapping problems or other random behaviour.  In
locore.s there is a routine called "Fastreclaim" which "knows" about
the core map structure.  What it knows is the size of the structure
and the location of two one-bit fields within it.  Therefore if you
make any changes to this structure you have to change the code in
locore.s.  One suggestion that was made was to make the size of the
structure and the offsets to these fields #defines in the cmap.h file.
I hope that the people at Berkeley take this suggestion and put it in
the next release.  What I did to solve the problem was to increase
the size of the "mdev" field in the core map structure and move the
field that followed it to the end of the structure.  This way the offsets
to the two other fields remained constant and I only had to change one
line in locore.s.  If you want to know the specific changes that I made,
send me mail and I will send you a diff listing.  If I get enough
requests I will post it to the net.
-- 
Dave Brierley
Raytheon Co.; Portsmouth RI; (401)-847-8000 x4073
...!decvax!brunix!rayssd!dhb ...!allegra!rayssd!dhb ...!linus!rayssd!dhb

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

Date: Mon, 29 Apr 85 13:42:19 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: malloc/calloc and portable software?

> 	The question is: does it hold that calls to {c,m,re}alloc can be
> safely intermixed on other Unix systems (S5, 4.1, v7, whatever).  I seem
> to remember getting into trouble with stuff like this on v6.

The answer is: yes and no.  All versions of calloc() that I have seen
after V6.X call malloc().  But I don't remember any guarantee anywhere
that they will continue to do so, especially on non-UNIX systems.

	Joe Yao		hadron!jsdy at seismo.{ARPA,UUCP}

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

Date: Mon, 29 Apr 85 13:36:32 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: Safe version of system(3) call.

It may be secure.  It will not do what you expect.  Whenever you use
fork(), etc. you should always check for errors.  You should also exit
at the end of your fork'd activities.  E.g.:
{
	register int pid;
	int status;

	switch (pid = fork()) {
	case 0:		/* child */
		setgid(getgid());
		setuid(getuid());
		exit(system(string));

	case ERROR:	/* error, -1 */
		fprintf(stderr, "Can't Fork or Whatever\n");
		return(ERROR);

	default:	/* parent, waits up for child. */
		while ((wret = wait(&status)) != pid) {
			if (wret == ERROR)
				return(ERROR);
		}
		break;
	}
	return(status);
}
Incidentally, this creates a second, intermediate sub-process.  If
you don't want this, you are better off modifying system() itself.

	Joe Yao		hadron!jsdy at seismo.{ARPA,UUCP}

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

Date: 29 Apr 85 12:50:16 CDT (Mon)
From: ihnp4!oliveb!jerry
Subject: Safe version of system(3) call.

[The originally posted routine]
should also do a setgid(getgid()) before the setuid so that set group
ID programs are also protected.  This also is inefficient in that an extra
fork is done.  Doing the code inline instead of calling system(3) would be
more efficient.  With access to the system(3) source you could easily make
a copy differing only in name and the setgid() and setuid() calls.

				Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry

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

Date: 27 Apr 85 21:19:08 CST (Sat)
From: ihnp4!lzwi!psc
Subject: SVR2 termio(7) common misunderstanding

> OK, I give.  I have been trying to get Hack 1.0.2 running on a 3B20
> w/ SVR2.  The program appears to start ok, but you must enter
> exactly four commands to get any response.
> ....
> Then to get any more action, you have to enter four more
> commands, and until you do, there is no output to your terminal.
> ....    It's always four, as near as I can tell.
> .....  The input appears to be read OK, just in these weird four
> command chunks.

Oh, I've seen *this* one before!  Since Unix System III, the termio(7)
structure has had an array of user definable control characters, e.g.,
character erase (# by default, but usually ^H).  The problem is, two
of these entries are overloaded.  They mean EOF and <something else>
when canonical processing (e.g., treating the number sign or backspace
as somthing special), and and time and character counts when canonical
processing is off.  So hack turns off canonical processing, and the
next read(2) from the terminal waits until it gets four characters,
because c_cc[VMIN] = c_cc[EOF] = cntl(D) = 4.  If you'd redefined the
EOF character to ^Z, you'd need to type 26 commands before hack saw any
of them.  Got it?

The fix is to find where canonical processing is turned off, and make
sure c_cc[VMIN] is set to 1 (and c_cc[VTIME] is set to 0, which means
no timeout when c_cc[VMIN] > 0).

[Ed note:  RTFM!  :-)  RWH.]

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

Date: Sun, 28 Apr 85 20:09:28 EST
From: Doug Gwyn <ucbvax!gwyn at BRL.ARPA>
Subject: Which IPC for passing control?

Joe Yao said that pipes are slow because they use disk.
This is a common misconception; in fact, the 4.2BSD socketpair
pipes ("no disk") have been measured as having less throughput
than real pipes/FIFOs.  If the block I/O system has sufficient
block buffers configured, then pipe traffic will seldom result
in real disk read/writes but rather will run out of the block
buffers in the kernel.

The problem with using signals for IPC is that they do not
have bulletproof semantics.  For example, there is a timing
window between the time that a process is switched to its
signal handler and the earliest moment that the process can
arrange to have a subsequent signal of the same type trapped
or ignored.  The 4.2BSD redesign of signals solves a lot of
these problems at the cost of compatibility with other versions
of UNIX.

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

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)