Copyright (c) 1985, 1993
The Regents of the University of California. All rights reserved.

%sccs.include.redist.roff%

@(#)acucntrl.8 8.2 (Berkeley) 12/11/93

C 6 acucntrl - turn around tty line between dialin and dialout /usr/lib/uucp/acucntrl keyword ttyline

Acucntrl turns around the terminal line, enabling it to be used for both dialin and dialout. On dialin a terminal line is assumed to have modem control enabled and a getty process in existence waiting for logins. On dialout modem control is disabled and there is no getty process.

This program must be run setuid to root.

keyword is chosen from the list: disable or dialout , to condition a line for dialout; and enable or dialin , to condition a line for dialin.

When the line is conditioned for dialing out, the login name of the real uid of the process is placed in /etc/utmp in capitals. This declares that the line is in use and acts as an additional locking mechanism. Acucntrl will refuse to act if the /etc/utmp entry for the line is not null, is not the the user's login name (capitalized or not), and if the process is not running as the superuser. The last condition is to allow the superuser to clear the state of the line.

Turning modem control on or off is handled by poking into /dev/kmem. It is currently implemented for dz, dh, and dmf lines.

Under 4.2 BSD the program will also refuse to disable a line if carrier is sensed on it. This is to avoid the dead period where someone has just dialed in and made the connection but has not yet logged in.

Ttyline can be either of the form tty* or /dev/tty*. Enabling/disabling a line whose name does not begin with ttyd? is prohibited unless the real uid of the process is 0 or if the login name corresponding to the real uid is uucp. This is a security precaution.

Steps taken when disabling ( i . e . setup for dialing out)

check input arguments look in /etc/utmp to check that the line is not in use by another user disable modem control on line check for carrier on device change owner of device to real uid edit /etc/ttys, changing the first character of the appropriate line to 0 send a hangup to process 1 to poke init to disable getty post uid name in capitals in /etc/utmp to let world know device has been grabbed make sure that DTR is on

Steps taken when enabling ( i . e . setup for dialing in)

check input arguments look in /etc/utmp to check that the line is not in use by another user make sure modem control on line is disabled turn off DTR to make sure line is hung up condition line: clear exclusive use and set hangup on close modes turn on modem control edit /etc/ttys, changing the first character of the appropriate line to 1 send a hangup to process 1 to poke init to enable getty clear uid name for /etc/utmp

First written by Allan Wilkes (fisher!allan)

Modified June 8,1983 by W.Sebok (astrovax!wls) to poke the kernel rather than use a kernel hack to turn on/off modem control, using a subroutine stolen from a program written by Tsutomu Shimomura {astrovax,escher}!tsutomu

Worked over many times by W.Sebok ( i . e . hacked to death)

/dev/kmem, /vmunix, /etc/ttys, /etc/utmp, /dev/tty*

Sensing carrier requires the 4.2 BSD TIOCMGET ioctl call. Unfortunately this ioctl is not implemented in the vanilla 4.2 BSD dh driver even though the dz and dmf drivers use an emulation of the DH11's modem control bits. This has been fixed here.

Some time (currently 2 seconds) is required between disabling modem control and opening the device. This is probably because of a race with getty whose open is finally being allowed to complete. This time interval may not be enough on a loaded system. Because of this problem and the above problem with the dh driver there is deliberately no error message given when the TIOCMGET ioctl fails.

Previously there were similar synchronization problems with the init process. When dialins are disabled the capitalized name of the process cannot be posted into /etc/utmp until init has finished clearing /etc/utmp. However one does not know how long that will take, and, on a loaded system, it can take quite a while. This was solved by the strategy of 1) posting the name, 2) poking init, 3) going into a loop where the process repeatedly waits a second and checks whether the entry has been cleared from /etc/utmp, and 4) posting the name again.