application with suid bit set on linux can't exec

[ranajitgh]

Want to setup web server so that fastcgi stub will be running as root when web server instance runs as normal non privilege user say webservd. I set ownership of fastcgistub directory to webservd and ran chmod 4755 on fastcgistub executable (owned by root). I have entered dependent library path into /etc/ld.so.config and ran ldconfig.
While processing fastcgi request I get stub connection failure. From strace output I see following problem:-

web server has started fastcgistub application and it has forked a child process. But It is failing to call execv. While debugging found all the required parameters are correct. It is same when suid is not set and web server works fine.
Even I can execute that command from command line. What could be problem here?

Following the same process I can run successfully on solaris using crle command for global linking.
I tested on linux 2.4.21-9 and linux 2.6.9-67, in both case found fastcgistub fails to call execv.

Here, File system is default and no nosuid or user option present.

What could be the problem? Please help.

Regards
Ranajit

[Rubberman]

Shared libraries also have execute permissions, and if it is loading a shared library that isn't owned by root, then that MIGHT cause this problem. That's the only thing that comes to mind right now (it's 11:30pm here and I'm getting tired after a 3 hour session helping someone get their wireless working).

[ranajitgh]

Thanks for taking time inspite of your grueling schedule.
Do you mean need to set suid bits for libraries also. Though I am not sure what is the reason, but gave a try but had no effect on the problem, still same behaviour.

[Rubberman]

No. You shouldn't need to suid the libraries. They are being loaded in the context of root by the suid application that uses them. However, some check that the library is owned by root and fail to load if not because it might be a trojan, or infected in some way since it isn't owned by root (trusted).

[ranajitgh]

OK. I found the root cause here. From strace output found that web server (non privilage user) were trying to connect to the UDS created by stub (suid to root). This socket by default had permission srwxr-xr-x i.e. others didn't have write permission. Though other unix systems also create same permission for UDS but everyone can connect but linux does not allow others to connect. I had to make it srwxrwxrwx so that non privilage user also can connect.
stub to work properly this connect had to succeed. Once this was resolved application started working.

[Rubberman]

A good case for decent error messages and diagnostics in programs. "Error - unable to open /dev/xyzzy, permission denied" or something like that would have given a good hint where to look, I think.