Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!lll-winken!uunet!visdc!jiii
From: jiii@visdc.UUCP (John E Van Deusen III)
Newsgroups: comp.unix.questions
Subject: Re: again
Summary: The setuid(getuid()) construct and the setuid bit
Message-ID: <518@visdc.UUCP>
Date: 20 Apr 89 23:32:46 GMT
References: <1051@aplcen.apl.jhu.edu> <510@visdc.UUCP> <1066@aplcen.apl.jhu.edu>
Reply-To: jiii@visdc.UUCP (John E Van Deusen III)
Organization: VI Software Development, Boise, Idaho
Lines: 41

In article <1066@aplcen.apl.jhu.edu> Ken Arromdee writes:
> ... [In article <510@visdc.UUCP> John E Van Deusen III writes:] 
>> You have declared getuid() to return an unsigned short.  Setuid
>> expects its argument to be an int.  Lint(1) complains.
>
> I just tried it again, only adding a cast to int.  The same problem
> happened.  This was expected, since C (at least pre-ANSI) widens
> arguments of short to int.  Thus, setuid would be getting an int
> anyway, despite the fact that I omitted the cast.

For the record, if getuid() returned type short it would be converted to
type int when being evaluated as a function parameter, and lint(1) would
not complain.  Since it is of type unsigned short, it is converted to
unsigned int, and that is not the same thing.

I did not mean to imply that the type cast alone would solve the
problem.  I just thought that fixing the program to pass lint(1) would
prove beneficial in debugging it.  The second thing that lint(1) says
about the program is that setuid(2) returns a value that is ALWAYS
ignored.  Since setuid(2) returns -1 and sets errno upon detection of an
error, isn't that return value of some interest in solving this problem?
Probably not in reality.  When this problem was posted to
comp.unix.wizards, article <470@holin.ATT.COM> by bes@holin.ATT.COM was
posted in reply:
	...
	I tried it (wrote a uids program) and did not see this results
	on a 3B4000 running 3.1.5 release of UNIX.
	-- 
	Bradley Smith
	Computer Systems Offer Integration Laboratory
---->	AT&T Bell Labs, Holmdel, NJ 
|	201-949-0090 att!holin!bes or bes@holin.ATT.COM
|
I would tend to believe that the program works.  So whats left?  Is it
possible that in all of the machinations of program development,
Mr. Arromdee has ended up with a version of his own utility program for
determining the user id, uids, that has the setuid bit set?
--
John E Van Deusen III, PO Box 9283, Boise, ID  83707, (208) 343-1865

uunet!visdc!jiii