filepro and file permissions

[Bob Stockler]

Mark Luljak wrote (on Fri, Apr 27, 2007 at 05:13:44PM -0400):

| 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.

That explains a lot.

When I had a Linux system running, as I recall, linking /bin/sh to
/bin/pdksh, rather than to /bin/bash, screwed up booting Linux.

Maybe linking /bin/sh to /bin/ksh (the Real KornShell, which is available
for -free-)  might work for filePro -and- booting Linux.

Maybe it would be so simple as having filePro recognize the environmental
parameter SHELL for executing its programs, rather than just defaulting to
/bin/sh, and SHELL could point to any shell that suited the user's needs.

Bob (whose environment includes SHELL=/bin/ksh)

-- 
Bob Stockler +-+ bob at trebor.iglou.com +-+ http://members.iglou.com/trebor