By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,870 Members | 1,212 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,870 IT Pros & Developers. It's quick & easy.

cuserid returns original login after a su to another user

P: n/a
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
Oct 17 '06 #1
Share this Question
Share on Google+
24 Replies


P: n/a
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
Oct 17 '06 #2

P: n/a
David Mathog <ma****@caltech.eduwrote:
#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.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Oct 17 '06 #3

P: n/a
Christopher Benson-Manica wrote:
David Mathog <ma****@caltech.eduwrote:
>#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.)
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
Oct 17 '06 #4

P: n/a
On Tue, 17 Oct 2006 11:16:57 -0700, David Mathog <ma****@caltech.edu>
wrote:
>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/WG...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

--
Al Balmer
Sun City, AZ
Oct 17 '06 #5

P: n/a
Al Balmer wrote:
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/WG...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
Oct 17 '06 #6

P: n/a
David Mathog <ma****@caltech.eduwrote:
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.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Oct 17 '06 #7

P: n/a
David Mathog wrote:
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
Oct 17 '06 #8

P: n/a
David Mathog <ma****@caltech.eduwrites:
Al Balmer wrote:
>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/WG...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")

?
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 17 '06 #9

P: n/a
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
Oct 17 '06 #10

P: n/a
On Tue, 17 Oct 2006 20:31:10 GMT, Keith Thompson <ks***@mib.org>
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.
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.

--
Al Balmer
Sun City, AZ
Oct 17 '06 #11

P: n/a
Al Balmer wrote:
On Tue, 17 Oct 2006 20:31:10 GMT, Keith Thompson <ks***@mib.org>
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.

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
Oct 17 '06 #12

P: n/a
"Default User" <de***********@yahoo.comwrites:
Al Balmer wrote:
>On Tue, 17 Oct 2006 20:31:10 GMT, Keith Thompson <ks***@mib.org>
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.

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!"
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 17 '06 #13

P: n/a
David Mathog wrote:
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
Oct 18 '06 #14

P: n/a
Igmar Palsenberg <ig***@palsenberg.localwrote:
David Mathog wrote:
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().
In ISO C? Not very likely.

Richard
Oct 18 '06 #15

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
(someone else)
>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.
"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.

Oct 18 '06 #16

P: n/a
Igmar Palsenberg wrote:
David Mathog wrote:
>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().
There are no such routines in ISO C, the subject of this group.
Please don't give misinformation.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Oct 18 '06 #17

P: n/a
Keith Thompson <ks***@mib.orgwrote:
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.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Oct 18 '06 #18

P: n/a
Christopher Benson-Manica <at***@otaku.freeshell.orgwrites:
Keith Thompson <ks***@mib.orgwrote:
>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.
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.
Oct 18 '06 #19

P: n/a
On Wed, 18 Oct 2006 16:32:24 +0200, Richard <rg****@gmail.comwrote:
>Christopher Benson-Manica <at***@otaku.freeshell.orgwrites:
>Keith Thompson <ks***@mib.orgwrote:
>>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.

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.

--
Al Balmer
Sun City, AZ
Oct 18 '06 #20

P: n/a
Al Balmer <al******@att.netwrites:
On Wed, 18 Oct 2006 16:32:24 +0200, Richard <rg****@gmail.comwrote:
>>Christopher Benson-Manica <at***@otaku.freeshell.orgwrites:
>>Keith Thompson <ks***@mib.orgwrote:

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.

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.
Did you read what I said? Again for your
edification and delight:

>>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.
If you don't agree fine. But kindly don't tell me what I may and may not
write if I think it is constructive and helpful.
>
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.
I have no idea what you are raving about. Or are you just being an
arrogant prick?
Oct 18 '06 #21

P: n/a
Igmar Palsenberg wrote:
David Mathog wrote:
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().
That's POSIX, among other things, not ANSI C.
Oct 18 '06 #22

P: n/a
On Wed, 18 Oct 2006 17:34:41 +0200, Richard <rg****@gmail.comwrote:
>Al Balmer <al******@att.netwrites:
>On Wed, 18 Oct 2006 16:32:24 +0200, Richard <rg****@gmail.comwrote:
>>>Christopher Benson-Manica <at***@otaku.freeshell.orgwrites:

Keith Thompson <ks***@mib.orgwrote:

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.

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.

Did you read what I said? Again for your
edification and delight:

>>>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.

If you don't agree fine. But kindly don't tell me what I may and may not
write if I think it is constructive and helpful.
I think it's you who are not reading. I did not tell you what not to
write. (However, you seem to be telling me what not to write.) I was
simply speculating on your reason for not agreeing with the obvious
reasons for not "mentioning possible solutions" to off-topic
questions. When you do so, you are not really doing the questioner any
favors. If you really think you have the answer, redirect the
questioner, then go to that forum and answer it there, where your
answer can be peer-reviewed and possibly even improved upon.
>
>>
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.

I have no idea what you are raving about.
Try re-reading it, slowly and carefully.
Or are you just being an
arrogant prick?
If you like.

--
Al Balmer
Sun City, AZ
Oct 18 '06 #23

P: n/a
Richard <rg****@gmail.comwrites:
Christopher Benson-Manica <at***@otaku.freeshell.orgwrites:
>Keith Thompson <ks***@mib.orgwrote:
>>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.

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.
Here's the problem: Some of us here are experts on standard C. Fewer
of us are experts on Unix and POSIX. Worse, some of us might *think*
we're experts on Unix and POSIX even if we're not.

Suppose somebody asks a question that turns out to be Unix-specific.
I post a followup:

Sorry, standard C doesn't have that feature. Try
comp.unix.programmer -- but in the meantime, I think the
getfoobar() function will solve your problem.

Then somebody else posts a correction:

The getfoobar() function is Linux-specific; didn't the OP say he
was using Solaris?

and another:

Actually, getfoobar() is supported on Solaris 10.

And yet another:

The Solaris getfoobar() function is subtly different from the
Linux getfoobar() function. Here are the gory details. [...]
But on any POSIX system, you can achieve the same affect with
getfoo(getbar(getuid())). Oh, wait, you need to use getruid(),
unless it's after dark on a Tuesday

and it finally turns out that I misunderstood the OP's actual problem,
and the whole discussion has been off-topic *and* a waste of time.

Or, I post a followup to the original post:

Sorry, standard C doesn't have that feature.
Try comp.unix.programmer.

and the OP goes off to a forum filled with experts on Unix
programming, and gets a quick, useful, and correct solution to his
prpblem, and we can spend our time here talking about standard C.

See the difference?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 18 '06 #24

P: n/a
Keith Thompson said:

<snip>
>
Here's the problem: Some of us here are experts on standard C. Fewer
of us are experts on Unix and POSIX. Worse, some of us might *think*
we're experts on Unix and POSIX even if we're not.

Suppose somebody asks a question that turns out to be Unix-specific.
I post a followup:

Sorry, standard C doesn't have that feature. Try
comp.unix.programmer -- but in the meantime, I think the
getfoobar() function will solve your problem.

Then somebody else posts a correction:
<bad scenario snipped>

Or, perhaps, somebody else /doesn't/ post a correction, and the OP is left
with the wrong answer. Either way, the OP loses.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 19 '06 #25

This discussion thread is closed

Replies have been disabled for this discussion.