Permissions on a SCO Unix exported file

[Brian K. White]

---top---
then: gosub exp
then: out("1")=1
then: out("2")=2
then: out("3")=3
then: end
exp:
then: export ascii out = (fn)   r=\n  f=\t
then: return
@once:
then: fn(128,*,g)="/u/" {@ID {"/HDrun.txt"
then: system ">"<fn
then: ' optional, write a header record with field names...
then: ' out("1")=fieldname("1") ; ... ; out("3")=fieldname("3") ; gosub exp
then: end
---bottom---


general way to think of it is,
* that which fp creates, only fp has permission to further modify, or even read.
* only system(), or anything else such as the parent process that ran fp, has the ability to create a file with open-enough permissions to ensure that some other process will be able to read/modify/delete it.

Depending on your platform, system usually runs as the user, where fp runs suid filepro
so, the export command, if the file has never existed yet, results in the export command creating the file.
That means rreport created the file, that means user filepro created the file.
Buy contrast a system() command runs as the user (frank, sally, etc...) and any files that get created in there get created (by default) owned by that user with permissions according to whatever umask was when they ran rreport.

That's half the problem and not necessarily a problem if that were all there was to it.
The other half of the problem is that when fp creates a file it does so with 600 permissions and fp provides no way to control that.

The _correct_ solution is for fp to provide a means to specify what perms are used to create files,
 or barring that it should _at least_ honor the umask that was in effect from which rreport ran.
Those are both standard behaviour any app should have.
IE: you should be able to say umask 002, and then run report/clerk, and then whenever repot/clerk creates a file itself (due to export, printer file, open() etc... NOT system ) the file should get created with 664 permissions.

Since neither of those is true, you are left with the pretty inefficient necessity of running at least one system() command before any export command, purely for no other reason than so that the file gets created with permissions you can specify, so that later some other process has permission to touch it.
But I want to stress that this is merely the only way to get the job done in fp, NOT that this is the right way. The right way is not possible.

"the only way" doesn't mean the exact code above or even the use of system(), it means the need to create the file any other way you want before and instead of allowing clerk/report to create it. Many times it's possible and more efficient if you process lends itself, to crete the file in the parent shell script before running clerk/report. For a typical cgi or cron job I usually generate a unique temp file name in the parent shell script, create the file, and hand the file name to fp via -r and/or via an environment variable.
In that case, since there is a parent shell script anyways and this clerk/report process is dedicated purpose, it's "free" to create the file in the parent and then just have fp use it. That save spawning yet another process for system() inside of fp.

There is a possible kludge I haven't tried yet, there is a PFUMASK which perversely only applies to commands I _never_ use, jsfile and html.
That is such a no-brainer that it should apply to open() if nothing else, but anyways...
Perhaps a more efficient, if less transparent to future readers of the code, answer is available by using pfumask and jsfile or html just for the purpose of getting the file created, with controllable permissions, without having to use system().

Thats worth investigating as it would be more efficient cpu & io wise.
Also it would be less likely to encounter some odd compatibility problem in the future as the code is moved to different platforms and as the underlying OS and shell evolves over time. system() launches a shell and you write commands that will work in that shell. Simple commands aren't likely to break over time and across platforms, but they are far more likely to break than a built-in fp command.

It is often OK, and not a bad idea at all, to allow fp to create a file if you know that only fp will need to access it. For example, you could write an export directly, or use printer file "filename", etc, no pre-creating, and then later in the same or in any other fp process, you can can import it, export more (append/overwrite), open(), read(), close(), remove(), because all that happens as the same user filepro that created the file.

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

  ----- Original Message ----- 
  From: Mike Schwartz 
  To: 'Filepro-List at Lists. Celestial. Com' 
  Sent: Thursday, October 18, 2007 10:42 AM
  Subject: Permissions on a SCO Unix exported file


  SCO Open Server 5.0.7 and fP 5.0.05

   

            What is the best way to change permissions on an exported spreadsheet?  I am trying to put the output spreadsheet into the subdirectory of the user who is running the process:

   

  144  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -

           If:

         Then: fn="/u/" {@ID {"/HDrun.txt" {""     '"Run line" file name

  145  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -

           If: 'Write out a "run line" spreadsheet...

         Then: export ascii RHD = (fn)   r=\n  f=\t

  146  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -

           If:

         Then: system "chmod a+rw" <fn {""

   

       filePro initially creates a 0 byte file, but then, even with this chmod system command, I still get this error:

   

  *** A System Error Has Occurred ***

   

  On File: /u/schwm/HDrun.txt

  Output Processing

  Line Number: 145

  export ascii RHD = (fn)   r=\n  f=\t

  ^

  filePro Error Number: -1

   

       What is the best way to do this?  Should I use another system command to create the output file first, then do a chmod on it? Should I do a pushenv umask command?

   

       I'm going to have to write several of these exports, so I would like to do the simplest coding possible.

   

  Thanks!

   

  Mike Schwartz

   

       



------------------------------------------------------------------------------


  _______________________________________________
  Filepro-list mailing list
  Filepro-list at lists.celestial.com
  http://mailman.celestial.com/mailman/listinfo/filepro-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20071018/3e3b1afe/attachment.html