Question about /var/spool/sockets/pwgr

[William McElvain]

I manage Three HP L2000 servers and all three have a common software baseline. However, I have notice a big difference in the contents of the /var/spool/sockets/pwgr directory. Here is an example of one of the links in this directory.

srwxrwxrwx 1 root sys 0 May 5 15:55 client3063

On two of the servers the typical number of links is around 30 to 50, but on one of the servers that number can get to be around 1700.
I'm not sure why this is and I'm not sure what these links are used for. Can any help?

[Mel Burslan]

The server with the higher number of socket files could be the one which gets the most user connection. That may explain why. ther than that, I can not think anything else.

[Patrick Wallek · Accepted solution]

The pwgr directory is used by the pwgrd daemon (password and group caching daemon) I believe.

How many users do you have defined on the machine with 1700 entries there? Most likely you have a lot more people connecting to that machine than you do to the others. If that is the case then this makes perfect sense.

If you want more information on pwgrd's function do:

# man pwgrd

I personally prefer to just turn this off. I don't have that many users connecting so I don't think there is that much of a benefit to letting pwgrd run and use resources itself.

[A. Clay Stephenson]

This simply reflects the number of passwd and/or group lookups by the processes (as opposed to users) on the systems. Run pwgr_stat on the boxes and I suspect you will see a difference. By the way, you can completely disable pwgrd and the system will run just fine. In a few cases, pwgrd gets stale entries and has toi be restarted.

[William McElvain]

Clay,

I'm a fairly inexperienced SA and the few UNIX books I have fail to cover the pwgr. I looked at the man pages for pwgrd, but I'm still unsure on how to disable this daemon or how to restart it. I would guess that if I changed the /etc/rc.config.d/pwgr file to read PWGR=0 that would effectively disable it by not enabling it at start up, but I'd like a little more information.
1. How do you disable the pwgr daemon?
2. How do you restart the pwgr daemon?
3. What effect on the system would deleting all of the links within /var/spool/sockets/pwgr have?

Also I read in the /etc/rc.config.d/pwgr file that since pwgrd is a proxy service with root privledges, it would allow any cleint program to see encrypted passwords. If this is true why would you ever want to have this daemon enabled?

[Mel Burslan]

to disable this daemon, you need to edit the /etc/rc.config.d/pwgr file and set the value of the variable PWGR to 0. As it is running on your system, it should have the value 1 on your copy of this file. This takes care of the automatic restart of the daemon on the next reboot. To shut it down right away right now, run the command :

/sibn/init.d/pwgr stop

after stopping the daemon, I do not see any reason why not to remove the socket files.

And just to clarify on point, yes this daemon is running with root privileges but it is not a proxy and it will not let any client to see the encrypted passwords. It is just a facilitator to speed up the password lookups where there are too many login/out transactions on the server. At least this is my understanding of what the purpose of this daemon. So, it is not a security risk.

HTH.

[A. Clay Stephenson]

Yes, you can disable it by setting PWGR=0 in /etc/rc.config.d/pwgr and UNIX boxes ran literally for decades without this daemon. It's not a bad daemon because otherwise a linear search of the passwd file or database is done for each getpwnam() or getpwuid(); pwgrd is used to cache these searches. The question you raise has to do with running pwgrd in conjunction with NIS+ and yes it that environment a client can get access to the hashed passwd so that an attack by a guessing utility like Crack could be used.

By the way, I should add that one way the socket files could be left in /var/spool/sockets/pwgr is through killing the pwgrd especially via kill -9 so that no cleanup is possible.