- If you take the wheel entry out of /etc/group and turn on NIS,
the '+:*::' line is incorrectly flagged as the entry for wheel (the
empty gid section is translated to 0), hence getgrgid() returns '+'
as the name of the group instead of 'wheel.'
- Using just '+:' as the 'turn on NIS' switch in /etc/group makes
getgrgid() dump core because of a null pointer dereference. (Last
time I was in here, I foolishly assumed that fixing the core dump
problems with getgrnam() and getgrent() would fix getgrgid() too.
Silly me.)
- it succeeded on non-directories (see POSIX 5.1.2.4).
- it hung on (non-open) named pipes.
- it leaked memory if the second malloc() failed.
- it didn't preserve errno across errors in close().
of the plus or minus lists at all, reject him. This lets you create
a +@netgroup list of users that you want to admit and reject everybody
else. If you end your +@netgroup list with the wildcard line
(+:::::::::) then you'll have a +@netgroup list that remaps the
specified people but leaves people not in any netgroup unaffected.
add #includes for YP headers when compiling with -DYP to avoid some implicit
declarations.
getgrent.c & getnetgrent.c: add some #includes to avoid implicit declarations
of YP functions.
remapping mechanism in the following manner: if given an entry +@foo
and there is no netgroup named 'foo,' try searching for a regular
user group called 'foo' and build the cache using the members of
group 'foo' instead. If both a netgroup 'foo' and a user group 'foo'
exist, the 'foo' netgroup takes precedence, since we're primarily
interested in netgroup matching anyway.
This allows access control schemes based on ordinary user groups
(which are also available via NIS) rather than netgroups, since
netgroups on some systems are limited in really brain-damaged ways.
my network because setnetgrent() was trying to do a lookup on group "".
It seems that an attempt to do a yp_match() (and possible yp_next())
on a null or empty key causes Sun's ypserv in SunOS 4.1.3 to exit
suddenly (and without warning). Our ypserv behaves badly in this
situation too, thoush it doesn't appear to crash. In any event, getpwent,
getnetgrent and yp_match() and yp_next() are now extra careful not to
accidentally pass on null or empty arguments.
Also made a small change to getpwent.c to allow +::::::::: wildcarding,
which I had disabled previously.
- Have the +@netgroup/-@netgroup caches handle the +user/-user cases too.
- Clean up getpwent() to take advantage of the improved +user/-user handling.
work because parse_netgrp() doesn't recurse properly. Fixed by
changing
if (parse_netgrp(spos))
return(1);
to
if (parse_netgrp(spos))
continue;
inside parse_netgrp(). (Lucky for me I happen to have a fairly complex
'live' netgroup database to test this stuff with.)
- Added support for reading netgroups from NIS/YP in addition to the
local /etc/netgroups file. (Note that SunOS and many other systems only
support reading netgroups via NIS, which is a bit odd.)
- Fix Evil Null Pointer Dereferences From Hell (tm) that caused
parse_netgrp() to SEGV when expanding netgroups that include
references to other netgroups. Funny how nobody else noticed this.
This is the first step in implimenting +@netgroup substitution in
getpwent.c and any other places that could use it and don't already
support it (which is probably everywhere).
by heading off possible null pointer dereferences in grscan(). Also
change getgrnam() slightly to properly handle the change: if grscan()
returns an rval of 1 and leaves a '+' in the gr_name field and YP is
enabled, poll the YP group.byname map before giving up. This should
insure that we make every effort to find a match in the local and
YP group databases before bailing out.
in an (unlikely) border case (maxgroups==1 and the user is on
an /etc/group line for the same group and that group only ...).
Now this case is dealt with as before ...
Add a missing apostrophe that suggests inverting the frequency to get
tick size. It read better before because `CLK_TCK' suggests a tick
size although it is actually a frequency.
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.
- 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.
