Operating System - HP-UX
1753851 Members
7644 Online
108807 Solutions
New Discussion

The dark side of NIS+ (or setuid)

 
Johan_52
Advisor

The dark side of NIS+ (or setuid)

A call getpwnam("johan") fails if the calling program is owned by johan, has the setuid bit set and is executed by root. The user root is defined in the /etc/passwd file, the user johan resides in the NIS+ tables. The NIS+ databases are stored on the server on which the program is executed. Executing by any other user (non root), anywhere is the network works OK, executing the program as root on other systems that use the same NIS+ server also presents no problem. Removing the setuid bit also solves the problem, but since my whole security is built around this feature, that is no option for me at this moment.
The errorcode I get from getpwnam is 'Permission denied', but I must admit that I didn't set errno to 0 before calling getpwnam, so it might be a left over from the program initialization (getpwnam is the first executable statement in the program). I tried switching real and effective uids in the program, but to no avail, also calling endpwent() before calling getpwnam does not help.

My primary question is why is the program behaving differently if the setuid bit is set, and I use setresuid to set the real user id to 'root', which works under other circumstances.
It looks like some different mechanism is used to retrieve user information if the program has the setuid bit and is executed by root, but how ?.
Is there any documentation available somewhere that explains these dark details.

Hope somebody can shed some light on this

Thanks in advance


Johan
1 REPLY 1
Michael Steele_2
Honored Contributor

Re: The dark side of NIS+ (or setuid)

Is there a conflict with 'nosuid' in /etc/fstab? If so remove the nosuid option from the /etc/fstab file, then unmount and remount the directory and try again.
Support Fatherhood - Stop Family Law