getlogin (3) -- a summary

Rick Lindsley richl at daemon.UUCP
Tue Feb 5 11:10:48 AEST 1985


A while back I posted a question on what to do with getlogin(3) (it
fails miserably on pty's that are not login ptys's). I promised a
summary of responses; here they are. Only 3 responses though.. I'd say
that in the interests of speed and compatibility that we will likely
just fix the individual programs to check the result from getlogin(),
and change getlogin only as indicated in the first letter (we have
people who have to have the original functionality (buggy though it may
be) and so can't really change the behavior of getlogin() too much).

--------

    From: dce at hammer (David Elliott)
    To: daemon!richl
    Date: Thu, 17 Jan 85 00:52:36 PST
    Organization: Tektronix, Wilsonville OR


    We went ahead and changed getlogin() to return NULL when it would have
    returned a "". This made su and a couple of other programs work
    correctly for us.

			    David


--------

    From: tektronix!decvax!mcnc!jte
    To: decvax!tektronix!daemon!richl
    Date: Thu, 17 Jan 85 12:58:45 est
    Original-From: James Ellis <jte at mcnc>
    Organization: Microelectronics Center of NC, RTP, NC

    Some sites have modified the kernel to track the user's name and
    make it available via a system call. If you don't have such mods
    or are not inclined to put them in, I recommend the following:

	    If getpwnam(getlogin()) returns the same uid as getuid(),
	    then use getlogin().
	    Otherwise, use the name returned by getpwuid(getuid()).

    Getlogin is not to be trusted as an identifier of "who" one "is".  A
    user should be considered to be who his permissions are - and that is
    defined by the uid. The only complication is that it is reasonable for
    a uid to be shared by several different logins, wherefore the first
    case above.

    Note that this is my opinion which is not, unfortunately, shared by
    all.  Berkeley in particular prefers to consider that you "are" your
    uid in some cases (permission checks) and you "are" who you logged in
    as in other cases (e.g. mail).  This allows folks to login as foo, su
    to root, and send mail that looks like it came from foo.  This is fine
    and well, but I also think it is wrong.  Since I don't have time to
    re-write mail myself, I don't complain too loudly.  I'd be interested
    to know what you finally decide to use.

				    Jim Ellis


-------

    From: j at utah-cs.arpa
    To: richl at tektronix.csnet
    Date: Fri, 18 Jan 85 12:33:11 MST

    Over all those alternatives I would choose:
    Find it via getpwuid.  Only if that fails (hardly ever), then look at
    utmp. Looking at utmp first gives the wrong result for programs which
    have been left in the background and then someone else logs in. I believe
    dmr recommended this himself a long time ago.

    I haven't done it here yet tho, as a problem may be that this might change
    getlogin's behavior in some instances such as mail's determining the
    sender, when the sender may be su'ed or something of that sort, or a
    privileged sender, etc.  Haven't really examined these potential problems
    though.

    {ihnp4,decvax}!utah-cs!lepreau



More information about the Comp.unix.wizards mailing list