61 Commits

Author SHA1 Message Date
Bill Paul
9531ca9353 Phew! Done at last: getpwent now understands +@netgroup/-@netgroup directives
in addition to the existing NIS substitutions. I may tweak this a bit in
the future, but the important stuff is all here.
1995-03-23 00:59:15 +00:00
Bill Paul
d66efc62bd Collapsed _masterpw_breakout_yp() and _pw_breakout_yp() into a
single function.
1995-02-05 02:12:49 +00:00
Bill Paul
a393cc06f5 Fixed a rather serious bug that presents itself when FreeBSD is configured
as an NIS client. The pw_breakout_yp routines that are used to populate the
_pw_passwd structire only do anything if the bits in the pw_fields member
_pw_passwd are cleared. Unfortunately, we can get into a state where
pw_fields has garbage in it right before the YP lookup functions are
called, which causes the breakout functions to screw up in a big way.
Here's how to duplicate the problem:

- Configure FreeBSD as an NIS client
- Log in as a user who's password database records reside only in
  the NIS passwd maps.
- Type ps -aux

Result: your processes appear to be owned by 'root' or 'deamon.'
/bin/ls can exhibit the same problem.

The reason this happens:

- When ps(1) needs to match a username to a UID, it calls getpwuid().

- root is in the local password file, so getpwuid() calls  __hashpw()
  and __hashpw() populates the _pw_passwd struct, including the pw_fields
  member. This happens before NIS lookups take place because, by coincidence,
  ps(1) tends to display processes owned by root before it happens upon
  a proccess owned by you.

- When your UID comes up, __hashpw() fails to find your entry in the
  local password database, so it bails out, BUT THE BITS IN THE pw_fields
  STRUCTURE OF _pw_passwd ARE NEVER CLEARED AND STILL CONTAIN INFORMATION
  FROM THE PREVIOUS CALL TO __hash_pw()!!

- If we have NIS enabled, the NIS lookup functions are called.

- The pw_breakout_yp routines see that the pw_fields bits are set and
  decline to place the data retrieved from the NIS passwd maps into the
  _pw_passwd structure.

- getpwuid() returns the results of the last __hashpw() lookup instead
  of the valid NIS data.

- Hijinxs ensue when user_from_uid() caches this bogus information and
  starts handing out the wrong usernames.

AAAARRRRRRRRRGGGGGGHHHHHHHHHH!!!

*Please* don't tell me I'm the only person to have noticed this.

Fixed by having __hashpw() check the state of pw_fields just before
bailing out on a failed lookup and clearing away any leftover garbage.
What a fun way to spend an afternoon.
1995-02-03 01:09:35 +00:00
Bill Paul
320ce7b758 Fix for that last fix... pass the hat. :) 1995-02-01 20:09:00 +00:00
Bill Paul
c768efa1a8 Small fix to _getyppass(): sometimes we can construct the wrong mapname
when looking for master.passwd.whatever.
1995-02-01 20:06:33 +00:00
Bill Paul
d0ef66889a Some changes for YP password map handling:
- FreeBSD's NIS server can supply a master.passwd map, which has
  more fields in it than a standard passwd map, so we need a
  _master_pw_breakout() fuction.

- When doing passwd map lookups, look for master.passwd.* by attempting
  a _yp_first() on master.passwd.byname. If it exists, we're being served
  by a FreeBSD NIS server and we should use this map.

- If we aren't the superuser, retrieve only the standard passwd maps.
  If we're being served by a FreeBSD system, then the passwd map has
  no passwords in it, and it won't serve us the master.passwd map unless
  we're superuser anyway.

There's a small speed hit for the superuser inherent in the check for
the master.passwd map, but this lets us dynamically decide what to do
rather than rely on a non-standard config file somewhere. Since all
of this is bypassed for normal users, they shouldn't notice the
difference.
1995-01-31 10:04:18 +00:00
Garrett Wollman
bb38a730ff Fix unbalanced #endif introduced by yesterday's change. 1995-01-19 19:01:50 +00:00
Garrett Wollman
c7da24ddb6 Prevent sites from shooting themselves in the foot while enabling/disabling
YP by disallowing `+' entries as logins in all cases.  (This handles the
case of a `+' entry in the password file but YP not running, which should
never happen but is easy enough to check for so we'll apply some
prophylaxis.)
1995-01-17 23:17:38 +00:00
Garrett Wollman
468bb86a7d Second half of YP security hole fix. Needs updated password
database in order to operate.
1994-09-20 21:42:12 +00:00
Garrett Wollman
d5b7518d9c Re-implement YP password file support from scratch. This implementation
correctly handles +user entries and + entries with local overrides.
1994-09-20 01:23:45 +00:00
Rodney W. Grimes
58f0484fa2 BSD 4.4 Lite Lib Sources 1994-05-27 05:00:24 +00:00