PFSYSEUID and RHEL 5

[Fairlight]

On Mon, Jun 08, 2009 at 08:13:29AM -0400, Dave may or may not have
proven themselves an utter git by pronouncing:
> We're in the process of migrating from SCO Openserver 6 to Red Hat
> Enterprise 5.  In this new environment a lot of our processing is
> breaking.  On SCO the SYSTEM command ran as the filepro user,
> presumably because dreport is setuid filepro.  Thus files created by
> processes under the SYSTEM command were owned by the user filepro.  On
> Linux the behavior we're seeing is that files created by the SYSTEM
> command are owned by the user logged into the machine.
> 
> We have a lot of processing that depends on the old behavior so it
> would be a rather massive undertaking to rewrite all this code.  The
> documentation for the PFSYSEUID variable seems to indicate that it
> will do exactly what we need.  The problem though is that no matter
> how I set it (PFSYSEUID=YES or PFSYSEUID=ON) I'm not seeing any
> difference.
> 
> I'll toss out the disclaimer that I'm not a filepro programmer; I'm
> the admin for our filepro server.

Good, then you'll understand the mechanics of why it doesn't work more
readily than most fP programmers.

Basically, the variable only makes a difference on systems where running a
command through SYSTEM results in the command being run by the user filepro
by default.  You can turn this behaviour -off-.

You can -not- turn it -on- when the system is incapable of handling it by
nature.

In the case of linux distributions, bash serves as /bin/sh.  It entirely
replaces stock Bourne shell.  Bash (since some vintage I can't
remember...maybe about 1.2?) -drops- all SUID privileges at start, unless
you specify a flag to prevent it.

One problem: in this case bash is sitting between filePro and your target
program. filePro's SYSTEM() calls C's system(2), which invokes a copy of
/bin/sh.  There is no way to get that appropriate flag to bash without
hacking and recompiling glibc--and that would be bad, as it'd be a global
change.  The variable in question can't alter the behaviour of system(2);
it can only force a dropping of privileges before the system() on systems
where the privileges would carry on naturally (SCO).  Essentially, one of
the acceptable values is a complete no-op by its very nature.

Your best bet is to toss all your fP users into sudo with the ability to
run the target commands as filepro, then change all the filePro SYSTEM
calls to call sudo as a prefix to the actual command.  It's probably still
a lot of work, but it'll be less work than trying to work around all the
files being owned by different people if you've depended upon them being
owned by filePro all this time.

mark->
-- 
"I'm not subtle. I'm not pretty, and I'll piss off a lot of people along
the way. But I'll get the job done" --Captain Matthew Gideon, "Crusade"