Cached FD in getpwuid_r() /getpwname_r() API

[MasthanD]

Hi All,

1. I wrote  a simple C program as below.

int main()
{

struct passwd p, *pp;
char buf[10240];
int bufLen = 10240;
int ret = 0;
int id;

pp = (struct passwd *)0;
ret = getpwuid_r(10, &p, &buf[0], bufLen, &pp);
close(3);
pp = (struct passwd *)0;
ret = getpwuid_r(120, &p, &buf[0], bufLen, &pp);
pp = (struct passwd *)0;
ret = getpwuid_r(1200, &p, &buf[0], bufLen, &pp);
return 0;
}

2. When I start the above C program from tusc utility, it is observed that the API getpwuid_r() communicating with some daemon .

1. Could you please let me know to which daemon it is communicating?
2. Could you please let me know the reason for communication?
3. Is there a way to avoid/skip the daemon communication? 

3. I also observed that the getpwuid_r() caching its socket and using the same socket for communication in subsequent getpwuid_r() calls.

 Could you please let me know if there is a way to avoid this caching business?

4. Could you please let me know if there is a way to get the FD details of getpwuid_r()?

Thanks

[Duncan Edmonstone]

What does your /etc/nsswitch.conf file say for passwd? If for example your system is configured to use LDAP, I could understand why it would want to open a socket to communicate with another process, poetntailly not even on the same host...

Out of interest, why do you care?

[MasthanD]

Hi Durcan

1. My /etc/netswitch.conf has the following entries for password

password: files

2. At somepoint of time, i want to close all the fds opened by my application.  My application incorrectly closes the fd which belongs getpwnam_r().  I dont want to close the FD which is not  opened  by my application.

Is there a way to identify the FD which belongs to getpwname_r() ? or

is there a way to avoid socket creation  in getpwaname_r()

Thanks,

Masthan

[Duncan Edmonstone]

I can't see this behaviour when I compile and run this code on my system (which is an 11.11 system so may be older). What tusc command do you issue, and can you show some example lines from the tusc output that lead you to the conclusions above...

Incidentally you might want to look at the man page for pwgrd - assuming you have root priviliges you might want to experiment with disabling pwgrd and seeing if this makes any difference.

[KishJ]

Greetings,

Please check if /etc/nsswitch.conf is configured. If not, I suggest that you enable it (by copying any of the default files /etc/nsswitch.*) as follows:

passwd:       files
group:        files
hosts:        files [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] dns [NOTFOUND=return]
services:     files
networks:     files
protocols:    files
rpc:          files
publickey:    files
netgroup:     files
automount:    files
aliases:      files

ipnodes:      files

This way we will be sure that /etc/passwd file will be used for user-name and password.

Then, check for the internal calls using the tusc as:

# /usr/local/bin/tusc -D -E -T "%M:%S" -a -f -l -o /tmp/tusc01.out -w all <program>

Sharing the above out output file (-o /tmp/tusc01.out) will help in answering your questions.

[KishJ]

Hi,

Any luck on the above? Please post your results for continued help.