filepro and file permissions

[Fairlight]

On Fri, Apr 27, 2007 at 04:53:48PM -0400, Dan Coutu may or may not have
proven themselves an utter git by pronouncing:
> Am I right in thinking that filePro explicitly sets the uid of any child
> process it creates to be the uid of the process that invoked filePro?
> (Rather than letting the child process use the 'filepro' uid?)

No.

On systems like SCO, child processes of SYSTEM() will run as 'filepro'.

On system like linux with bash v2 or higher, the same processes will run as
the UID rather than the EUID.  This is because, without a special flag as
an argument, bash drops EUID before doing anything.  Since system(2) is
hardwired into libc without the flag, you're basically screwed there.

It's actually the shell that decides to keep or drop EUID, however--filePro
always hands off its EUID, it's in what the child chooses to do with it.

The ultimate solution to this would be to rewrite SYSTEM so that it doesn't
rely on system(2), but rather uses something in the exec family of
functions.  However, since this would require rewriting shell globbing and
a fair amount of other syntax, it actually will likely never happen.  A
thought, however, would be to include a public domain Bourne shell -with-
fP, use the exec class of functions, and pass the actual command in as
arguments to it.  This -should- (if my brain is turned on today) result in
identical behaviour to system(2), but allow fP-Tech to provide a standard
shell across all platforms.  Of course, they'd need to compile/maintain
that shell as well.  I don't even want to guess what's involved on Windows.

Let's just say I don't ever see it being 'fixed'.  It's doable, but not
within the limitations of what I think most companies would put up with,
including mine.  Which isn't a criticism...it's like saying I should
maintain and bundle perl with LightMail.  Just isn't going to happen.

mark->
-- 
print("Content-Type: person/now-desceased\n\n");
# The only good MIME is a dead MIME.