Root running Informix utilities via su -c

This dead horse has had the flesh flayed from its bones years ago, but I discovered a new twist -- which purportedly didn't work. I attempted to run an alter statement during a postinstall script in a Solaris pkgadd package thus: su informix -c "alter table bla add (col1 char)"|dbaccess databasename On one database -- which some dork had granted privileges to root -- the statement ran just fine; the other, configured correctly for production, received "No connect permission" error. Fine and well -- CDI posts from 4/2001 indicate this should happen. However, I implemented the workaround from those posts which should have failed, but didn't: I modified the postinstall script to cat out the alter statement to a file; chowned the file to 'informix' and chmoded it SETUID, too; then had root execute the file as informix: su informix -c commandfile WTF? It worked this time. So: Executing from the command line won't work, but from a SETUID script file it does. Can somebody (Jonathen?) explain this weird phenomenon? -- in one case dbaccess is getting the real userid of 'root', in the other case 'informix', all by chmod'ing 4xxx? Running IDS 7.31.UC-4 on Solaris 2.7/Intel (don't ask).

On Mon, 20 Oct 2003 09:56:24 -0400, Red Valsen wrote: Su only forks once which leaves the real user id accessible. But the SETUID bit causes the shell to perform a fork also after changing the userid which now, along with the fork performed by the 'su informix', makes for two forks as 'informix' which obliterates the original real userid. That's how it's done in servers that need to run as a particular user with their real and effective userids changed - fork twice after changing user ids. Art S. Kagel > This dead horse has had the flesh flayed from its bones years ago, but I > discovered a new twist -- which purportedly didn't work. > > I attempted to run an alter statement during a postinstall script in a Solaris > pkgadd package thus: > > su informix -c "alter table bla add (col1 char)"|dbaccess > databasename > > On one database -- which some dork had granted privileges to root -- the > statement ran just fine; the other, configured correctly for production, > received "No connect permission" error. Fine and well -- CDI posts from > 4/2001 indicate this should happen. However, I implemented the workaround > from those posts which should have failed, but didn't: I modified the > postinstall script to cat out the alter statement to a file; chowned the file > to 'informix' and chmoded it SETUID, too; then had root execute the file as > informix: > > su informix -c commandfile > > WTF? It worked this time. So: Executing from the command line won't work, > but from a SETUID script file it does. Can somebody (Jonathen?) explain this > weird phenomenon? -- in one case dbaccess is getting the real userid of > 'root', in the other case 'informix', all by chmod'ing 4xxx? > > Running IDS 7.31.UC-4 on Solaris 2.7/Intel (don't ask).