filepro and file permissions

[Brian K. White]

----- Original Message ----- 
From: "Bob Stockler" <bob at trebor.iglou.com>
To: <filepro-list at lists.celestial.com>
Sent: Friday, April 27, 2007 7:46 PM
Subject: Re: filepro and file permissions


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

Lots of scripts on linux incorrectly expect bash and only bash.
Linking sh to anything but bash, on linux, is a bad idea.
Unless your goal is to ferret out all such dependancies.
In that case it's a great idea.


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

Wasn't there a project at some point to give fp a generic, agnostic, 
scripting interface?
I thought the idea was you could say "my script interpreter is X" somewhere, 
and then all your menu command lines, menu F5 batch files, system comands, 
maybe even printer destination commands, would get run by that interpreter, 
which could be perl or anything not just some variant of bourne shell.

Support nightmare? Of course.
Cool idea? I thought so, but I didn't have to try to write it.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!