> Actions to be performed at login and logout time would be controlled
> by two files: /etc/tty_login and /etc/tty_logout respectively.  Both
> would use the same format, and would be processed by a single library
> function to be added to libutil.  The file format would be lines of
> the form:
> 
> 	# comment line
> 	tty_name	shell_command
> 
> The format could (optionally) be extended to allow multi-line
> commands by continuing onto the next line when a backslash is
> the last character on the line.  [ Is this desirable? ]

I don't care one way or the other...  8-)

> The tty_name would be matched against the name of the current
> tty line so all lines (and only those lines) with he tty_name
> field matching would be processed.
> 
> The shell_command field would be run as 'sh -c "shell_command"'
> with the following environment variable guaranteed to be set:
> 
> 	USER=user_name

I would say that you also want the name of the tty that they're
logging in to or out of...  That way i could write one big program,
that handled all of the actions for all of my ttys, rather than having
to have lots of little scripts...

a default path would be nice, too...  8-)


> This format allows simple commands to be specified directly as
> a shell command, and more complicated processing could be done
> with an external program.  Here are examples of each:
> 
> Example /etc/tty_login file:
> 	# This line just needs one related device chown'ed
> 	/dev/wsconsole		chown ${USER} /dev/wsmouse
> 	# This line has several related devices, which are
> 	# handled by the external program /etc/console.sh
> 	/dev/kdconsole		/etc/console.sh login
>
> Example /etc/tty_logout file:
> 	# This line just needs one related device chown'ed
> 	/dev/wsconsole		chown root /dev/wsmouse
> 	# This line has several related devices, which are
> 	# handled by the external program /etc/console.sh
> 	/dev/kdconsole		/etc/console.sh logout

I would suggest that the tty names as used in these files be the same
as those in /etc/ttys, unless there's a good reason to do otherwise.


> Here is a proposed interface for the new libutil function:
> 
> void tty_relatives(char *filepath, char *ttyname, char *username);
> 
> 	filepath: one of:
> 		_PATH_TTY_LOGIN 	("/etc/tty_login")
> 		_PATH_TTY_LOGOUT 	("/etc/tty_logout")
> 	
> 	ttyname:  name of the tty getty runs on (i.e. /dev/console)

again, why not as specified in /etc/ttys?


> The above function would be called by src/usr.bin/login/login.c
> just after it does the chown call to the tty line, i.e.:
> 
> 	tty_relatives(_PATH_TTY_LOGIN, ttyn, pwd->pw_name);
> 
> The same function would also be called by getty in main.c as:
> 
> 	tty_relatives(_PATH_TTY_LOGOUT, ttyn, "root");
> 
> just after it does its chown/chmod calls for the tty line.

This looks sane, to me...

> There may be better ways to communicate the various pieces of
> information like $USER in the call to tty_relatives(), and the
> name of that function is certainly open to improvments...

I see you're as good at naming functions as I am...  8-)


One possible adjustment: it may make sense to have the 'matching' code
support wildcards, either via glob-like syntax or regexps...

For instance, i can imagine wanting to do something like:

	tty[BC]?	serial_line_timer

where that action could start a process to limit total login time
allowed for that user on that tty, or something like:

	*		check_logger	

where that action may, say, want to check for logins by
individuals suspected of doing Bad Things, etc., and set up some type
of logging mechnism, or something...



cgd