I have an application that runs SUID. It is a purchased application so I can not exactly see what it is doing.

When I execute the program it is setuid to ID #200. I'm id #203.

If I use the application to create a file the file is owned by ID #200. So I'm assuming this is proof that the SUID bit is working as it should.

However when I escape from the application and create a file...
!ls > /tmp/file
the file is owned by me, ID#203. I wrote a little program and both the real and effective userids are #203...me!

So who is changing the effective UID back to me?

The application? - not sure why it would or even why it would care.
The Shell? - I've tried both bash and ksh with the same result.
Lunix? - does it eliminate the Effective UID across an Exec call? Can this be controlled?

We count on the effective UID staying until we want to remove it so that we can access protected files.

Thoughs?

Thanks
Bob

The application runs as user 200. When you exit the app you're yourself not 200, you're not in the application anymore. So.. working as designed?

I'm not exiting the app. I am ESCAPING from the app. Just as you would when using ! with in VI. Under Unix, when you escape from the app you maintain the userid and effective userid of the app.

So the app, still running, creates a shell. That shell then runs the command. However when we do this under Linux the effective user id of the shell reverts back to the userid.

Simple example would be the application wants to copy a file. So instead of writing the code to copy the file it calls the 'cp' command to do it. However the file is a protected file and can only be read by userid #200. This works fine under Unix since the cp command is run as userid #200 so it can read the file and copy it. The target file is also owned by user id #200.

However on Linux it appears the userid reeverts to #203. So the cp command can not read the file and therefore the file is not copied.

While this is a simple example we use this technique through out the application for anything from unix to dos conversions to printing.

So is there a way to make this work?

Bob

Ok... problem solved.

It turns out that the application will always execute shell commands using the command interpreter /bin/sh.

By default /bin/sh is linked to /bin/bash.

The bash manual page states:
If the shell is started with the effective user (group) id not equal
to the real user (group) id, and the -p option is not supplied, no
startup files are read, shell functions are not inherited from the
environment, the SHELLOPTS variable, if it appears in the environment,
is ignored, and the effective user id is set to the real user id. If
the -p option is supplied at invocation, the startup behavior is the
same, but the effective user id is not reset.

However this does not apply to either ash or ksh.

So by linking /bin/ksh to /bin/sh I get the behavor I need where
the EUID is preserved.

Thanks for all the suggestions.

Bob