7.0 & Mt. Xinu's getpwuid()

7.0 & Mt. Xinu's getpwuid()

Post by Barton E. Schaef » Sun, 18 Mar 1990 13:50:55

Quote:} Greetings Net-Land,
} We're running 4.3 More/BSD with NFS from Mt. Xinu on 2 VAX 11/780's.
} In init.c:init(), the call to getpwuid() gets stuck/never returns.
} Poking around the code for the C library, I've found that an RPC call
} within libc/yp/yp_match.c:yp_match() gets a bad exit status, so
} yp_match() sleeps for a few seconds and tries again.  Unfortunately, the
} RPC call never succeeds, so the function never exits.

The problem isn't getpwuid() itself, it's the combination with getuid().
I checked the Mt. Xinu man pages and /usr/include/{sys/types.h,pwd.h}
files and discovered:

    typedef u_short uid_t;

The man page says to declare:

    extern uid_t getuid();

but of course getpwuid() expects an int as argument, so it's throwing
an invalid uid around.  This doesn't cause any problems, apparently,
unless you are running yp (which we aren't).

You'll have to add a correct declaration for getuid() somewhere, and cast
the call in the argument of getpwuid() to int.

How the heck is one supposed to know how to portably declare things like
getuid()?  I presume uid_t is POSIX-compliant, but how do you detect at
compile time that such a typedef exists?  (And why the devil didn't Xinu
use the *same* type as the argument to getpwuid()?)
Bart Schaefer          "EARTH: Surrender IMMEDIATELY or we PICKLE DAN QUAYLE"



7.0 & Mt. Xinu's getpwuid()

Post by Jaap Akkerhu » Wed, 21 Mar 1990 03:07:16

Excerpts from netnews.comp.unix.questions: 17-Mar-90 Re: 7.0 & Mt.

Quote:>  (And why the devil didn't Xinu
> use the *same* type as the argument to getpwuid()?)

I don't know, but Unix is riddled with these inconsistencies. Scanning
for instance the AT&T SVID Issue 2, you will find that getuid() returns
an unsigned short while setuid just expect an int, so the common code
setuid(getuid()) is actually incorrect according to the SVID. It should
be setuid((int)getuid()).

Hopefully POSIX will get rid of all these problems, but I'm not holding
my breath. When X/Open was in the process of producing their first
version of the X/Open recomendations, they had corrected a lot of these
anomalies. However, they had to retract that version on order of AT&T.
This makes me wonder whether AT&T SVID will ever be POSIX compliant.