| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
authentication only). This comes handy when you're tight on space.
Submitted by: mostly John Baldwin <jobaldwi@vt.edu>
Reviewed by: John D. Polstra <jdp@polstra.com>
|
|
|
|
| |
logins get logged.
|
|
|
|
|
|
|
|
| |
Change login to use PAM for authentication. I kept the built-in
passwd/NIS authentication support, to handle cases where the system
is missing its "/etc/pam.conf" file. S/Key and KerberosIV
authentication methods are removed from the login program, but
still available in PAM modules.
|
|
|
|
|
|
| |
it's here to stay.
This code is starting to look almost reasonable again.
|
|
|
|
|
|
|
|
|
| |
not complete, and it hasn't been touched for 18 months. All the
ifdefs obfuscate the code. I discussed the LOGIN_CAP_AUTH support
with its author and he agreed that it is a dead end. I am bringing
PAM into the tree within the next two weeks. It is much more
flexible than LOGIN_CAP_AUTH, and will serve as a superior replacement
for it.
|
| |
|
| |
|
|
|
|
|
| |
PR: 6529
Submitted by: Dan Lukes <dan@obluda.cz>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libc/gen/getpass.c. The old behaviour of blocking SIGINT and not
changing SIGQUIT was restored in rev.1.5 of getpass.c. The change
here completely restores the old behaviour of not supporting killing
login with keyboard signals (only) at the password prompt. There
is no reason to support this, since login can be exited normally
by typing a couple of ^D's. Login certainly shouldn't dump core
in response to user input. Previously, SIGQUIT killed login
immediately but SIGINT killed it only after the password was
entered.
PR: 7444
|
|
|
|
|
|
|
|
| |
if LOGIN_CAP_AUTH was defined. This is kind of silly, because
LOGIN_CAP_AUTH doesn't work anyway, is not defined currently,
probably will never be defined, and IMHO should not be defined.
But I'm sure you'll sleep better tonight, knowing that these bugs
are gone.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here is a some example for avoiding a confusion.
It asssumes a logged host domain is "spec.co.jp". All
example is longer than UT_HOSTNAMELEN value.
1) turbo.tama.spec.co.jp: 192.19.0.2 -> trubo.tama
2) turbo.tama.foo.co.jp : 192.19.0.2 -> 192.19.0.2
3) specgw.spec.co.jp : 202.32.13.1 -> specgw
Submitted by: Atsushi Murai <amurai@spec.co.jp>
|
| |
|
|
|
|
|
|
|
|
|
| |
is on a NFS partion without root read access. Also, flip euid again for
the duration of the chdir() to the homedir for the same reason.
PR: 5145
Submitted by: Joel.Faedi@esial.u-nancy.fr
Also tested by: A Joseph Koshy <koshy@india.hp.com>
|
|
|
|
|
|
|
|
|
|
|
| |
for some DES passwords
crypt(real_password, salt)
is equal to
crypt("", salt);
It means that this user (and not only he) can login without
entering password at all, just pressing Return.
So if empty password entered and crypted password is not empty,
invalidate any crypt result by assigning ":"
|
|
|
|
|
|
|
|
|
| |
Otherwise, when pressing the INT ke at the password prompt, the password
will be displayed. Now login will be killed.
Probably the same will have to be done for the LOGIN_CAP_AUTH case.
I have not done that.
Reviewed by: Joerg Wunsch
|
|
|
|
|
| |
PR: bin/4801
Submitted by: mishania@demos.su (Mikhail A. Sokolov)
|
|
|
|
| |
Also quieten -Wall a bit.
|
|
|
|
|
| |
update man page. Add usage().
Obtained from: OpenBSD
|
| |
|
|
|
|
| |
auth_rmfiles() was being called in error without LOGIN_CAP_AUTH defined.
|
| |
|
|
|
|
| |
Fix incorrect bracket nesting. Closes PR#3144.
|
|
|
|
| |
posix standard on the topic.
|
| |
|
|
|
|
| |
the root password is empty.
|
|
|
|
|
| |
Rearrange validation logic so that it works correctly when
compiled with kerberos support. Closes PR#3056.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleanup of #ifdef's for LOGIN_CAP.
Fixed bug in empty shell (closes PR#2550).
Refused root logins now displays standard "Login incorrect" and
exhibits identical backoff behaviour to a failed login.
Cleaned up logging of refused logins.
Use #defines for login retries and backoff. Also implemented
definable variables if LOGIN_CAP is defined, with
"login-retries" and "login-backoff" as capabilities
in the default class (closes PR#2805).
TERM from previous environment is no longer truncated.
|
| |
|
|
|
|
| |
variable name (with different functionality)
|
|
|
|
| |
introduced by LOGIN_CAP
|
|
|
|
| |
THAT has been in here!).
|
|
|
|
|
| |
was caused by introduction of login classes. Closes PR bin/2550.
Added references to login.conf to manpage, crossreference to login.conf(5).
|
|
|
|
|
|
|
|
|
|
| |
Note that LOGIN_CAP_AUTH code (login authentication) is not (yet) enabled
and requires /usr/libexec/login_<style> authentication program support to
be added at a later date. The Makefile contains a macro LC_AUTH to turn
it on and prevent unnecessarily linking against skey/krb libs and the
addition of klogin.c module.
All other aspects of login_cap support are fully functional.
|
|
|
|
| |
to keep valid information in utmp and lastlog
|
|
|
|
| |
which is no longer bogusly installed in /usr/include.
|
| |
|
|
|
|
|
|
| |
defined.
Submitted by: Mark Murray <mark@grondar.za>
|
|
|
|
| |
Submitted by: Paul Traina <pst@Shockwave.com>
|
|
|
|
|
|
|
|
|
|
| |
1) Don't spit out an error message if Kerberos is installed but not yet
set up.
2) Don't attempt to verify the ticket you got back, as workstations
are not intended to have srvtab files of their own.
Both behaviors can be re-enabled with KLOGIN_PARANOID.
|
|
|
|
|
|
| |
Now password changed for right user and
no longer possible to skip password change.
I hope it will be ok....
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Accounts that have "pw_change" set, are supposed to change their passwords
by the date specified in "pw_change". If they have not changed their passwords
by that date, currently they get "LOCKED OUT" of the system. This is not the
correct behavior, the user should be prompt (forced?) to change their password
at this time. If the behavior of "pw_change" was meant to be a LOCKOUT,
then you should use "pw_expire".
Solution:
Instead of locking out the user, prompt them to change their password.
Reviewed by: jkh
Submitted by: rls
|
|
|
|
|
| |
Reviewed by:
Submitted by: guido
|
|
|