busybox/loginutils
Denys Vlasenko db5546ca10 libbb: code shrink: introduce and use [_]exit_SUCCESS()
function                                             old     new   delta
exit_SUCCESS                                           -       7      +7
_exit_SUCCESS                                          -       7      +7
run_pipe                                            1562    1567      +5
pseudo_exec_argv                                     399     400      +1
finish                                                86      87      +1
start_stop_daemon_main                              1109    1107      -2
shutdown_on_signal                                    38      36      -2
runsv_main                                          1662    1660      -2
redirect                                            1070    1068      -2
read_line                                             79      77      -2
pause_and_low_level_reboot                            54      52      -2
list_i2c_busses_and_exit                             483     481      -2
less_exit                                             12      10      -2
identify                                            4123    4121      -2
grep_file                                           1161    1159      -2
getty_main                                          1519    1517      -2
fsck_minix_main                                     2681    2679      -2
free_session                                         132     130      -2
fdisk_main                                          4739    4737      -2
clean_up_and_exit                                     53      51      -2
bsd_select                                          1566    1564      -2
bb_daemonize_or_rexec                                198     196      -2
------------------------------------------------------------------------------
(add/remove: 2/0 grow/shrink: 3/17 up/down: 21/-34)           Total: -13 bytes

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2022-01-05 22:16:06 +01:00
..
add-remove-shell.c config: update size information 2018-12-28 03:20:17 +01:00
addgroup.c libbb: reduce the overhead of single parameter bb_error_msg() calls 2019-07-02 11:35:03 +02:00
adduser.c libbb: reduce the overhead of single parameter bb_error_msg() calls 2019-07-02 11:35:03 +02:00
chpasswd.c tweak help texts 2020-12-16 01:19:08 +01:00
Config.src restore documentation on the build config language 2018-06-06 15:16:48 +02:00
cryptpw.c cryptpw: typo in usage message 2021-02-02 14:54:29 +01:00
deluser.c deluser: check if specified home is a directory before removing it 2020-06-09 18:04:31 +02:00
getty.c libbb: code shrink: introduce and use [_]exit_SUCCESS() 2022-01-05 22:16:06 +01:00
Kbuild.src
login.c libbb: code shrink: introduce and use [_]exit_SUCCESS() 2022-01-05 22:16:06 +01:00
passwd.c help text tweaks 2020-12-13 19:04:19 +01:00
README comment and readme updates 2016-11-04 14:13:58 +01:00
su.c *: more --help tweaks 2021-06-15 10:00:18 +02:00
sulogin.c libbb: exec_login_shell() - new function 2020-12-02 21:51:08 +01:00
vlock.c libbb: factor out fflush_stdout_and_exit(EXIT_SUCCESS) 2022-01-04 23:31:58 +01: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.