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.
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.)
getcwd() has two off-by-one bugs in FreeBSD-2.0:
1. getcwd(buf, size) fails when the size is just large enough.
2. getcwd(buf + 1, 1) incorrectly succeeds when the current directory
is "/". buf[0] and buf[2] are clobbered.
(I modified Bruce's original patch to return the proper error code
[ERANGE] in the case of #2, but otherwise... -DG)
This program demonstrates the bug:
---
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
int main(void)
{
char buf[5];
int errors;
errors = 0;
if (chdir("/tmp") != 0) {
perror("chdir");
abort();
}
if (getcwd(buf, 5) == NULL) {
perror("oops, getcwd failed for buffer size = size required");
++errors;
}
if (chdir("/") != 0) {
perror("chdir");
abort();
}
buf[0] = 0;
buf[2] = 1;
if (getcwd(buf + 1, 1) != NULL) {
fprintf(stderr,
"oops, getcwd succeeded for buffer size = one too small\n");
++errors;
}
if (buf[0] != 0) {
fprintf(stderr,
"oops, getcwd scribbled on memory before start of buffer\n");
++errors;
}
if (buf[2] != 1) {
fprintf(stderr,
"oops, getcwd scribbled on memory after end of buffer\n");
++errors;
}
exit(errors == 0 ? 0 : 1);
}
pointer returned by realloc(). All callers free the pointer if the
execve fails. Nuke the caching. This essentially restores buildargv()
to the 1.1.5 version. Also fix a memory leak if realloc() fails. Also
nuke similar but non-broken caching in execvp(). malloc() should be
efficient enough.
later be applied to a number of programs (inetd for instance) to clean
out the bogus code doing the same thing, modulus all the bugs.
If you need to read a '#'-is-a-comment-file, please use these routines.
I realize that the shlib# should be bumped (for the non-US world:
increased by something), but will defer this until something significant
happens.
!!!!!!!!
NB
!!!!!!!!
You MUST pwd_mkdb /etc/master.passwd before attempting to use the new
libc, or things may go wrong. (I doubt anything actually /will/ go
wrong, but the actual behavior is undefined. YOU HAVE BEEN WARNED.)
The database format is, however, backwards-compatible, so old executables
will still work.
are running under. Here's how to bootstrap (order is important):
1) Re-compile gcc (just the driver is all you need).
2) Re-compile libc.
3) Re-compile your kernel. Reboot.
4) cd /usr/src/include; make install
You can now detect the compilation environment with the following code:
#if !defined(__FreeBSD__)
#define __FreeBSD_version 199401
#elif __FreeBSD__ == 1
#define __FreeBSD_version 199405
#else
#include <osreldate.h>
#endif
You can determine the run-time environment by calling the new C library
function getosreldate(), or by examining the MIB variable kern.osreldate.
For the time being, the release date is defined as 199409, which we have
already established as our target.
