busybox/loginutils
James Byrne 253c4e787a Optionally re-introduce bb_info_msg()
Between Busybox 1.24.2 and 1.25.0 the bb_info_msg() function was
eliminated and calls to it changed to be bb_error_msg(). The downside of
this is that daemons now log all messages to syslog at the LOG_ERR level
which makes it hard to filter errors from informational messages.

This change optionally re-introduces bb_info_msg(), controlled by a new
option FEATURE_SYSLOG_INFO, restores all the calls to bb_info_msg() that
were removed (only in applets that set logmode to LOGMODE_SYSLOG or
LOGMODE_BOTH), and also changes informational messages in ifplugd and
ntpd.

The code size change of this is as follows (using 'defconfig' on x86_64
with gcc 7.3.0-27ubuntu1~18.04)

function                                             old     new   delta
bb_info_msg                                            -     182    +182
bb_vinfo_msg                                           -      27     +27
static.log7                                          194     198      +4
log8                                                 190     191      +1
log5                                                 190     191      +1
crondlog                                              45       -     -45
------------------------------------------------------------------------------
(add/remove: 2/1 grow/shrink: 3/0 up/down: 215/-45)           Total: 170 bytes

If you don't care about everything being logged at LOG_ERR level
then when FEATURE_SYSLOG_INFO is disabled Busybox actually gets smaller:

function                                             old     new   delta
static.log7                                          194     200      +6
log8                                                 190     193      +3
log5                                                 190     193      +3
syslog_level                                           1       -      -1
bb_verror_msg                                        583     581      -2
crondlog                                              45       -     -45
------------------------------------------------------------------------------
(add/remove: 0/2 grow/shrink: 3/1 up/down: 12/-48)            Total: -36 bytes

Signed-off-by: James Byrne <james.byrne@origamienergy.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2019-04-30 10:51:27 +02:00
..
add-remove-shell.c config: update size information 2018-12-28 03:20:17 +01:00
addgroup.c config: update size information 2018-12-28 03:20:17 +01:00
adduser.c adduser: fix a bug of getpwnam() overwriting shell name, closes 8586 2019-01-12 11:51:58 +01:00
chpasswd.c Optionally re-introduce bb_info_msg() 2019-04-30 10:51:27 +02:00
Config.src restore documentation on the build config language 2018-06-06 15:16:48 +02:00
cryptpw.c libbb: switch bb_ask_noecho() to "mallocing" string return API 2018-04-07 15:50:30 +02:00
deluser.c config: update size information 2018-12-28 03:20:17 +01:00
getty.c getopt32: remove opt_complementary 2017-08-08 21:55:02 +02:00
Kbuild.src loginutils/*: convert to new-style "one file" applets 2015-10-19 01:20:36 +02:00
login.c login: close PAM session on errors as well, not only on success 2019-01-22 17:04:16 +01:00
passwd.c Optionally re-introduce bb_info_msg() 2019-04-30 10:51:27 +02:00
README comment and readme updates 2016-11-04 14:13:58 +01:00
su.c config: deindent all help texts 2017-07-21 09:50:55 +02:00
sulogin.c Optionally re-introduce bb_info_msg() 2019-04-30 10:51:27 +02:00
vlock.c getopt32: remove opt_complementary 2017-08-08 21:55:02 +02:00

	Getty

??? Should getty open tty with or without O_NONBLOCK?
For serial lines, it means "should getty wait for Carrier Detect pin?"
I checked other getties:

- agetty always uses O_NONBLOCK
- mgetty uses O_NONBLOCK unless run with -b, or as "getty"

??? If we decided to use O_NONBLOCK (perhaps optionally with -b),
when getty should send -I INITSTR data to tty? After open succeeds?
What if we also want to initialize *modem* with some AT commands?

??? Should we check/create /var/lock/LCK..ttyPFX lockfiles?

??? mgetty opens tty but does NOT lock it, then waits for input via
select/poll, and when input is available, it checks lock file.
If it exists, mgetty exits (it assumes someone else uses the line).
If no, it creates the file (lock the tty). Sounds like a good algorithm
to use if we are called with -w...

Getty should establish a new session and process group, and ensure
that tty is a ctty.

??? Should getty ensure that other processes which might have opened
fds to this tty be disconnected? agetty has a -R option which makes
agetty call vhangup() after tty is opened. (Then agetty opens it again,
since it probably vhangup'ed its own fd too).

Getty should leave the tty in approximately the same state as "stty sane"
before it execs login program. Minor things we do conditionally are:
	c_iflag |= ICRNL; // if '\r' was used to end username

??? mgetty uses per-tty file to ignore connects, /etc/nologin.ttyxx -
is it useful?

It should be possible to run "getty 0 -" from a shell prompt.
[This currently doesn't work from interactive shell since setsid()
fails in process group leader. The workaround is to run it as a child
of something. sh -c 'getty - 0; true' usually works. Should we fix this?]
It should leave tty in a sane state when it exits (Ctrl-D, -t SEC timeout):
echo should be on, speed, control chars properly set, etc.
(However, it can't restore ctty. The symptom is that "</dev/tty"
fails in the parent shell after getty exits: /dev/tty can't be opened).

Getty should write LOGIN_PROCESS utmp record before it starts waiting
for username to be entered.

	Login

Login should not try to set up tty parameters - apart from switching echo
off while entering password, and switching it back on after.

Login should not leave "echo off" state when it times out reading password
or otherwise terminates (Ctrl-C, Ctrl-D etc).

??? Should login establish a new session and/or process group, and ensure
that tty is a ctty? Without this, running login directly (not via getty)
from e.g. initscript will usually result with a login session without
ctty and without session/pgrp properly created...

It should be possible to run "login [USER]" from a shell prompt,
and it should work (not block/die/error out).
Similarly to getty, it should leave tty in the sane state when it exits.

??? Should login write LOGIN_PROCESS utmp record before it starts waiting
for username/password to be entered?

Login should write USER_PROCESS utmp record just before it is about
to exec user's shell.