login.conf is a mechanism provided by all of the BSDs, which supply manual pages for it (q.v.).
The nosh toolset, in particular the userenv-fromenv command (and its userenv wrapper command) extends this to Linux-based operating systems; extends the mechanism with additional specific capabilities; and extends some FreeBSD enhancements to NetBSD and OpenBSD.
Its primary use is a way of setting user-preference and personalization environment variables at login
without needing to deal in the different "profile" files for the Z, Korn, Almquist, Watanabe, C, Tenex C, Bourne Again, and other shells (or a Hellish combined profile that has conditional code that attempts to detect what shell is interpreting it); and
without needing to grant users write access to files outwith their own home directories.
userenv-fromenv specifically deals only in environment variables.
It does not set resource limits or apply password/login controls.
(Indeed, the FreeBSD Handbook nowadays recommends that resource limits be applied in a different way, rather than via the login subsystem.)
The libutil library on the BSDs permits the capabilities files to be compiled to a Berkeley DB file (with cap_mkdb) which provides for much faster access.
On Linux-based operating systems, the workalike library that the nosh toolset uses does not have Berkeley DB file access methods and only uses the source text files.
It also does not support the tc= item for chaining capabilities.
SSH does not respect login.conf on any operating system, even though it really should do at least on the BSDs where it is a standard part of the base operating systems.
One can overcome this limitation of SSH by using the nosh toolset's chain loading and login subsystem tools, however.
Instead of just plain ssh -t -Y user@host, run:
% ssh -t -Y user@host unsetenv PATH userenv --default-path --default-tools --default-locale --default-timezone --toolkit-pager --set-other login-shell
Note: In Microsoft Terminal or MobaXTerm and suchlike GUI SSH front-ends, this is an entryfield in a settings dialogue and not a command line entered at a command interpreter, but it is pretty much an identical configuration.
userenv does the login.conf processing that SSH omits.
It does not need --default-term, of course.
unsetenv unsets the PATH environment variable, as otherwise a default set by SSH would be inherited causing userenv to leave the variable alone.
Finally login-shell runs the user's SHELL (which userenv has read from the user account databases) as a login shell.
An augmentation to login.conf available on FreeBSD, but not on bare NetBSD or OpenBSD, is the ability for users to have .login_conf files in their own home directories, which have a single "me" record that can override (only) environment variable settings from the administrator-set system login.conf file.
The nosh toolset makes this feature available on both NetBSD and OpenBSD.
Note:
The FreeBSD implementation introduces a weird corner-case security hole when a system administrator (bizarrely, but not impossibly) decides to have an actual login class named "me".
The nosh toolset avoids the particular FreeBSD library function that has this problem.
In the unextended mechanism, environment variables are set through the charset, lang, manpath, path, shell, term, timezone, and general setenv capabilities.
To these userenv-fromenv adds termpath, terminfopath, editor, visual, pager, and manpager (for details of which, see its manual page).
For examples:
A user can set private preference for the full-screen "visual" program, line-mode text editor programs, and for the manual pager to use.
me:\ :visual=nvim:\ :editor=nex:\ :manpager=most:
An administrator can globally set a termcap search path.
default:\ :termpath=/etc/system-control/convert/termcap/termcap.linux /etc/system-control/convert/termcap/termcap.teken /etc/system-control/convert/termcap/termcap.ms-terminal /usr/share/misc/termcap:
This was (and still is) possible with the general setenv capability, of course.
But these extensions permit some further common environment variables to be set without the complexities of embedding and escaping a path inside a comma-separated list inside a capability list, the same convenience as already available with the manpath capability.