cuserid returns original login after a su to another user

[David Mathog]

On a Solaris 8 system if a user "joe" logs in, for instance via ssh,
cuserid() returns "joe". That's the expected behavior and so far so
good. However if that user then does:

% su - sally

cuserid will still return "joe". However "sally" uses "tcsh" where
whoami shows "sally". If the user running as "sally"
creates a file the ownership is for "sally". "ps -ef"
also shows the user shell running as "sally". While "sally"
printenv and set don't show any "joe" assignments. All of this is
as expected except that cuserid() seems to hang onto "joe"
when all other programs see only "sally".

Is this the expected behavior of cuserid()?

If so, which is the proper function to use to return "sally"
following the su change to the "sally" account?

Thanks,

David Mathog

 

[David Mathog]

Here is example code for "test_cuserid.c":

#include <stdio.h>
#include <stdlib.h>
int main(void){
(void) fprintf(stdout,"cuserid:%s\n",cuserid(NULL));
exit(EXIT_SUCCESS);
}

Compiled with:

gcc -o test_cuserid test_cuserid.c

Note: on linux it works as expected following "su - sally" from "joe",
returning "sally". So far only on Solaris 8 does it return "joe" after
su to "sally".

Thanks,

David Mathog

 

[Christopher Benson-Manica]

#include <stdio.h>
#include <stdlib.h>
int main(void){
(void) fprintf(stdout,"cuserid:%s\n",cuserid(NULL));
exit(EXIT_SUCCESS);
}

(You will surely get much more helpful replies on
comp.unix.programmer, but FWIW my friendly man page says that
cuserid() has been obsoleted by getlogin(), which may or may not be
relevant to your situation.)

Your post is off-topic for comp.lang.c. Please visit

http://www.ungerhu.com/jxh/clc.welcome.txt
http://c-faq.com
http://benpfaff.org/writings/clc/off-topic.html

for posting guidelines and frequently asked questions. Thank you.

 

[David Mathog]

(You will surely get much more helpful replies on
comp.unix.programmer, but FWIW my friendly man page says that
cuserid() has been obsoleted by getlogin(), which may or may not be
relevant to your situation.)

Naturally the Sun man page says nothing like that, probably because
of the age of that release. The linux one says, near the bottom, to use
getpwuid(geteuid()) instead and not to use cuserid() at all!

This brings up an interesting point, is there some easy way to determine
which language standard (if any) a given C function belongs to? In
this case the linux man page has "conforming too" entries that
give a history of cuserid() but of course the Sun page says
nothing. In general they might both be out of date. The include in
both instances is "stdio.h", which gives no hint about how "standard"
the function is. Short of reading through that file there's no way to
tell what language "status" a given function has.

Is there a web page where one can punch in a C function name and
it will return the status of that function??? For instance, in
this case it would show something like:

cuserid:
System V present
POSIX added in 1988
POSIX removed in 1990
ANSI C not present

I'm not trying to pester the wrong group with these questions, often
as not I just don't have an easy way to determine if common C functions
are part of the language standard or part of the platform support.

Thanks,

David Mathog

 

[Al Balmer]

Is there a web page where one can punch in a C function name and
it will return the status of that function??? For instance, in
this case it would show something like:

cuserid:
System V present
POSIX added in 1988
POSIX removed in 1990
ANSI C not present

I'm not trying to pester the wrong group with these questions, often
as not I just don't have an easy way to determine if common C functions
are part of the language standard or part of the platform support.

The last is easy - just get a copy of the C language standard. If you
don't want to buy it from ANSI or ISO, the latest draft is at
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf

The general question is harder. The POSIX, SUS, and other standards
are available, of course, and some systems' man pages are helpful*,
but I don't know any single source I'd count on.

*HP-UX, for example, gives

STANDARDS CONFORMANCE
cuserid(): AES, SVID3, XPG2, XPG3, XPG4, FIPS 151-2, POSIX.1

 

[David Mathog]

The last is easy - just get a copy of the C language standard. If you
don't want to buy it from ANSI or ISO, the latest draft is at
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf

That is a very useful link, thanks.

I just looked through that PDF and did not find any function in ANSI C
that will report the user's name on a system directly. Is it
that ANSI C only supports finding a user name via something like

getenv("USER")

?

Thanks,

David Mathog

 

[Christopher Benson-Manica]

I just looked through that PDF and did not find any function in ANSI C
that will report the user's name on a system directly. Is it
that ANSI C only supports finding a user name via something like

getenv("USER")

Or by invoking system() with an appropriate argument. ANSI C has no
concept of "users" and indeed is often used to implement programs
running on embedded platforms where the concept is meaningless.

 

[jmcgill]

On a Solaris 8 system if a user "joe" logs in, for instance via ssh,
cuserid() returns "joe". That's the expected behavior and so far so
good. However if that user then does:

% su - sally

cuserid will still return "joe". However "sally" uses "tcsh" where
whoami shows "sally". If the user running as "sally"
creates a file the ownership is for "sally". "ps -ef"
also shows the user shell running as "sally". While "sally"
printenv and set don't show any "joe" assignments. All of this is
as expected except that cuserid() seems to hang onto "joe"
when all other programs see only "sally".

If you asked on comp.unix.programmer or a solaris newsgroup, I'm sure I
would suggest something along the lines of getting the real and/or
effective UID for the process, and if you actually wanted to decorate
that with a name, using getpwuid() to name it. Evidently cuserid() is
reporting "real" UID, and you want "effective" UID. man -s 2 getuid

 

[Keith Thompson]

That is a very useful link, thanks.

I just looked through that PDF and did not find any function in ANSI C
that will report the user's name on a system directly. Is it
that ANSI C only supports finding a user name via something like

getenv("USER")

?

No, ANSI C (more properly ISO C) has no way at all of finding a user
name, nor does it have any concept of users. Even on Unix-like
systems, getenv("USER") does not reliably tell you the user name, for
reasons I won't go into here.

We really can't help you here. Try comp.unix.programmer, or perhaps
comp.unix.solaris.

A note to the newsgroup: I'm inclined to think that answers of the
form:

Your question is off-topic; try asking in comp.something.else.

are actually more helpful than answers of the form:

Your question is off-topic; try asking in comp.something.else.
But here's a quick system-specific answer to your off-topic
question anyway.

 

[Default User]

Keith Thompson wrote:

A note to the newsgroup: I'm inclined to think that answers of the
form:

Your question is off-topic; try asking in comp.something.else.

are actually more helpful than answers of the form:

Your question is off-topic; try asking in comp.something.else.
But here's a quick system-specific answer to your off-topic
question anyway.

I heartily endorse this product and/or service.




Brian

 

[Al Balmer]

A note to the newsgroup: I'm inclined to think that answers of the
form:

Your question is off-topic; try asking in comp.something.else.

are actually more helpful than answers of the form:

Your question is off-topic; try asking in comp.something.else.
But here's a quick system-specific answer to your off-topic
question anyway.

Agreed, especially since the "quick system-specific answer" is often
wrong or incomplete. Even if it's correct, asking the question in the
right environment may get even better answers.

 

[Default User]

Agreed, especially since the "quick system-specific answer" is often
wrong or incomplete. Even if it's correct, asking the question in the
right environment may get even better answers.

Plus it all too frequently leads to, "I tried that but it didn't solve
the problem, what now?" The answer being, "Go away like we told you!"




Brian

 

[Keith Thompson]

Plus it all too frequently leads to, "I tried that but it didn't solve
the problem, what now?" The answer being, "Go away like we told you!"

Or, the answer being, "Sorry, we still can't help you here; you should
probably try a different newsgroup, as we originally advised you." I
don't know whether "Go away" was intended to be rude, but someone
could certainly take it that way.

 

[Igmar Palsenberg]

> That is a very useful link, thanks.

I just looked through that PDF and did not find any function in ANSI C
that will report the user's name on a system directly. Is it
that ANSI C only supports finding a user name via something like

Use geteuid() / getuid() combined with a getpwent().



Igmar

 

[Richard Bos]

Use geteuid() / getuid() combined with a getpwent().

In ISO C? Not very likely.

Richard

 

[Kenny McCormack]

Plus it all too frequently leads to, "I tried that but it didn't solve
the problem, what now?" The answer being, "Go away like we told you!"

(Good ole KT)
Or, the answer being, "Sorry, we still can't help you here; you should
probably try a different newsgroup, as we originally advised you." I
don't know whether "Go away" was intended to be rude, but someone
could certainly take it that way.[/QUOTE]

"Sorry, we still can't help you here; you should probably try a
different newsgroup, as we originally advised you." is just "Go away"
with a sugar-coating. No one is fooled by it.

If nothing else, I admire DefaultUser/Brian's honesty.

 

[CBFalconer]

Use geteuid() / getuid() combined with a getpwent().

There are no such routines in ISO C, the subject of this group.
Please don't give misinformation.

 

[Christopher Benson-Manica]

A note to the newsgroup: I'm inclined to think that answers of the
form:

Your question is off-topic; try asking in comp.something.else.

are actually more helpful than answers of the form:

Your question is off-topic; try asking in comp.something.else.
But here's a quick system-specific answer to your off-topic
question anyway.

I'm inclined to disagree, but as it seems that the consensus favors
your position, I will abide by it.

 

[Richard]

I'm inclined to disagree, but as it seems that the consensus favors
your position, I will abide by it.

If someone thinks its a C question, asks here it never hurts to mention
a possible solution at the same time as pointing them out to better
resources. I'm surprised anyone would think any different.

 

[Al Balmer]

If someone thinks its a C question, asks here it never hurts to mention
a possible solution at the same time as pointing them out to better
resources. I'm surprised anyone would think any different.

Perhaps you think that because your off topic answers are always
complete and correct, and nothing could be gained by asking them in
the proper forum.

OTOH, this is a problem for the rest of us. As the world learns about
your omniscience and infallibility, they will all come here with their
off topic questions, and there won't be time and space for topical
questions.