Permissions on a SCO Unix exported file

[Brian K. White]

Are you by chance allowing report to create the file as a print destination 
output? (-p filename)
For an export like this, I usually use a command like this:
rreport -fp processname -u <selection/other opts>
or
rreport -p processname -u <selection/other opts> -p /dev/null -pc nocodes

(yeah the -pt is probably superfluous...)

I preferr the first but sometimes I am actually using the output format to 
generate the data and for that you need the 2nd. Also in that 2nd case you 
need a "printer file filename" command in processing, _after_ the system() 
command that sets up the file.
That keeps rreport from trying to print the default print code tables 
printer init sequence somewhere, which it would normaly try to do so early 
that it's already too late to fix even in @once.
Just in case you happened to have -p filename on your command line and 
didn't mention that :)

I garuntee that the code I showed does not try to create the file until the 
first time gosub exp is actually encountered (executed) in the flow of 
processing, which in that example is not until after @once has run it's 
system() command.

And, the system() command will generally run as the user, who generally has 
permission to create files in his own directory. I did neglect one key 
detail but you only *might* need it, which is setting umask or running a 
chmod within the system command.
system "umask 0; >"<fn
or
system ">"<fn<";chmod 666"<fn

(I preferr the first)

That creates the file with 666 permissions.
Otherwise it would have probably been created with 644 permissions and owned 
by user frank, sally etc...
Without opening up the permissions like that, but just by creating it in 
system() first, filepro would still be able to read the file but not modify 
it. Subsequent system() commands or any other process running as the same 
user, would be able to delete it or re-write it. Thats often good enough and 
is both slightly safer and slightly less work.

Also, don't expect any of this to work even though it is all correct and 
tested forever, if you have previously created these files owned by fp or 
root with the default perms and haven't deleted them yet.

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" <mschw at athenet.net>
To: <filepro-list at lists.celestial.com>
Sent: Thursday, October 18, 2007 2:19 PM
Subject: RE: Permissions on a SCO Unix exported file


Brian White wrote:

> then: export ascii out = (fn) r=\n f=\t
> then: return
> @once:
> then: fn(128,*,g)="/u/" {@ID {"/HDrun.txt"
> then: system ">"<fn

     User "filepro" probably just doesn't have permission to create files in
the individual user subdirs (IE, /u/mike), even though all users are members
of the groups "filepro" and "group" and user filepro is a member of the
groups filepro and group.  For example, the permissions on "mike" are
drwxr-xr-x (note the lack of a "w" for group), so this code is not working,
even though we are in the same groups:

25  -------   -   -   -   -   -   -   -   -   -  -   -   -
        If:
      Then: fn(40,*)="/u/" {@ID {"/HDpurch" {fm {".txt" {""
26  -------   -   -   -   -   -   -   -   -   -   -   -   -
        If:
      Then: system ">" {fn {""
27  -------   -   -   -   -   -   -   -   -   -   -   -   -
        If:
      Then: system "chmod a+rwx" <fn {""
28  -------   -   -   -   -   -   -   -   -   -   -   -   -
        If:
      Then: export ascii HDO = (fn)   r=\n  f=\t

     I can't track it down any further using debug, because filePro appears
to be attempting to create the output files as specified on the output
statements -before- any other lines of code are executed.  For example, if I
start dreport with -db, at the first debug prompt that appears, I set a
breakpoint on line 25, but as soon as I press "C" to continue, I get the -1
filePro error.

    This leads me to believe that *nothing* I do inside my filePro output
processing code (even a "system "asroot"" file creation command) will have
any effect on this situation...

    Hmmm... maybe I could execute the "asroot" file creation command and
chmod if I put it into a sort/selection processing table...

    (I don't know if these permissions on /u/mike are "normal" for SCO
systems, but I wouldn't be permitted to change them for this particular
customer, anyway...)

Thanks,

Mike Schwartz


_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
http://mailman.celestial.com/mailman/listinfo/filepro-list