Does getpwuid work with /etc/shadow without root priviledge

[arking1981]

(re-post it to this column; firstly posted to languages and scripting; better to be here)

Dear all,

Can you please tell me if the routine getpwuid() works well with shadowed passwd as with /etc/passwd when using a non-root user to get its own hashed passwd (for some authentication in my application)?

I have tried to write a little program to get some user's hashed passwd through a NIS/shadowed system and succeded. But that may be different as NIS to me seems not of high security, because I can use ypcat -k to see the hashed texts as well. When the /etc/passwd and /etc/shadow are stored locally, I don't know if the hashed passwd can still be got by the user itself or must via root user.

I am learning to setup a shadowed test environment (will be very appreciated if someone kindly provides a guide). In the mean time, I would like to get double confirmation from experts here.

Please share you expertise.

Thanks a lot
Best regards
Kang

[Duncan Edmonstone]

I know nothing about the innards of the password system, but a quick view of the shadow(4) man page seems to indicate you should be using getspent(3c)

getspent() seems to work for standard passwd, shadow, and for trusted systems. I have no idea whether a non-root user can get the password hash out of it though... I thought the whole point of shadow was to prevent non-root users viewing the password hash.

HTH

Duncan

[Matti_Kurkela · Accepted solution]

Nope, a non-privileged user cannot call getspent() or getspnam() at all: you'll only get a NULL pointer and errno set to EPERM as a result.

The "traditional" way would be to create a minimal helper program to check the password and do nothing else: this program would be very carefully tested and then installed as setuid root (or setgid shadow, if the "shadow" group exists and has read-only access to /etc/shadow in your architecture). The application would then call this helper program to check the password.

This required each application developer to create his/her own helper programs if authentication was required and the application was not supposed to run as root. This led to a lot of developers doing essentially the same thing over and over, sometimes badly: for example, the password must not be passed to the helper program as a command-line argument, because command lines are visible to the ps(1) command, which is available to any user on the system.

To fix this, PAM was developed. It is quite a bit more complex, but essentially allows an unprivileged application to pass the username and password to the PAM library and receive a result that tells if it was correct or not.

As a side benefit, PAM allows the actual authentication mechanism to be replaced easily: by replacing one PAM component library with another that implements the same API, you can switch from local passwd/shadow authentication to authentication based on NIS, NISPLUS, LDAP, RADIUS or something else. If the application follows PAM specifications, no application-level changes are required for this.

I didn't find a HP-UX specific PAM programming API example, but I understand the PAM API is fairly generic. Here's one Linux document that includes programming example:

http://content.hccfl.edu/pollock/AUnix2/PAM-Help.htm

See the chapter titled "Under the Hood of PAM â A Programmers Perspective".

MK

[arking1981]

thank guys. it helps a lot.
points were assigned.