From: Casper H.S. Dik on
neilsolent <n(a)solenttechnology.co.uk> writes:

>Although Casper solved the problem I posted, I was trying to solve a
>problem with some 3rd party code, by simulating it in as simplified
>way. I thought I had reproduced the problem - but I hadn't!

>So I still have a mystery to solve as follows..

>The binary executable file jobman has the same permissions as sleep2
>did above, and is created as a child process of a process called
>"batchman". It resides on the root filesystem, which has the setuid
>capability. However, it still runs as user maestro, not root.

>I tried a truss of the parent process and can see it spawning jobman
>as follows:

>26890: execve("/opt/apps/maestro/bin/jobman", 0x001FF230, 0xFFBFF8AC)
>argc = 1
>26890: *** SUID: ruid/euid/suid = 4004 / 0 / 0 ***

>any further suggestions?

What is jobman? Is it a shell script?

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: neilsolent on
> What is jobman?  Is it a shell script?
>
> Casper

Hi

The file jobman is a binary executable, provided by IBM.
I have tracked down the problem further using truss:

26890: execve("/opt/apps/maestro/bin/jobman", 0x001FF230, 0xFFBFF8AC)
argc = 1
26890: *** SUID: ruid/euid/suid = 4004 / 0 / 0 ***
............
26890: getuid() = 4004 [0]
26890: setuid(4004) = 0


So it looks like the jobman process initially starts out with
effective userid of root (by virtue of its file permission) BUT the
code in jobman is calling getuid() then setuid() - I would expect
these to have the effect of restoring the effective id to the real id
(4004 = maestro). And that is exactly what I see.

So I put the whole problem down to a software (code) fault.


thanks
Neil