PFSYSEUID and RHEL 5

[Dave]

On Mon, Jun 8, 2009 at 2:36 PM, Fairlight<fairlite at fairlite.com> wrote:
> 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.

Egads what a mess!  From man system:
      Do  not  use  system()  from a program with set-user-ID or set-group-ID
      privileges, because strange values for some environment variables might
      be  used  to subvert system integrity.  Use the exec(3) family of func‐
      tions instead, but not execlp(3) or execvp(3).  system() will  not,  in
      fact,  work  properly  from  programs  with set-user-ID or set-group-ID
      privileges on systems on which /bin/sh is bash version 2, since bash  2
      drops  privileges  on startup.  (Debian uses a modified bash which does
      not do this when invoked as sh.)

So... do not use system() from an suid executable (like, say, dclerk)
where /bin/sh is bash?  Essentially don't use SYSTEM on Linux.  Thanks
for pointing this out Fairlight.  Though I'm more frustrated than ever
now this closes a few avenues we've been wasting our time on.

Just wondering... It's been suggested to me that ksh may be the way to
go.  In my tests replacing /bin/sh with a symlink to /bin/ksh gives
our developers the behavior they expect (files created with SYSTEM
show an owner of filepro).  I'm a bit scared that re-symlinking
/bin/sh is going to cause some unforeseen breakages somewhere else.
Has anyone else running ksh as /bin/sh and what should we look out
for?
-- 
-=[dave]=-

Entropy isn't what it used to be.