File permissions when using processing tables

[Fairlight]

>From inside the gravity well of a singularity, Matt Hersant shouted:
> I've a question regarding file permissions when using filepro processing 
> tables.  We've an input processing table which runs when a data is input 
> into a filepro file.  During this process, the fp code makes a system call 
> to append data to a text file, or uses sed to substitute in new data.  When 
> all is done the permissions of the text file have been changed to the Unix 
> account of the person who updated the filepro file.  I can't seem to figure 
> out why this is happening.  No chown is being called by the processing 
> table.  The file permissions are 666, so that it can be updated by anyone.  
> Any help or advised is appreciated.

Sounds like a linux system running bash v2.x.  It rescinds its EUID when
invoked unless you specify a command line flag, which is not possible when
it's invoked as /bin/sh from SYSTEM(), which calls system(3) internally.
It may very well be a different system type or shell, but this is almost a
signature issue.

When the shell drops the EUID privileges, it runs anything beneath that
shell under the real UID.  Hence, your ownership issues.

The mode 0666 is something fP-Tech has been aware of for many years with
EXPORT.  I personally filed a formal bug report over a year ago (closer
to two, methinks), and they apparently do not feel it is necessary to
fix the problem.  I've given up hope on that front, and relegate the
responsibility to the developer, where fP-Tech places it through inaction.
(Interestingly, EXPORT generates 0666, CREATE generates 0660, and OPEN
generates 0600.  This information was provided me fresh just this last week
by an fP developer.)

However, you say you're doing this through SYSTEM.  You don't, however say
how you're creating that file.  If it was SYSTEM to another fP process that
does an EXPORT, that's still internal to fP.  If it's whatever else you're
using (some other software, sed, awk, whatever), then it's a function of
your umask.  The solution to this is to put a "umask 077" in /etc/profile
or /etc/bashrc, whichever is applicable.  That will give you all 0600 files
unless a program explicitly uses another mode internally.

In the end, if you're using EXPORT, there are two ways to handle this
safely, one of which I've not tested, although I believe it should work:

1) Safe way with no race condition for data sniffing:  OPEN() and CLOSE()
the file with raw I/O commands in fP prior to doing an EXPORT.  If EXPORT
either truncates -or- appends without doing an unlink() on the file if it
already exists, this would result in the 0600 from OPEN sticking, as the
modes for open(2) are only used if the O_CREAT condition is utilised (it
has to create the file).  I haven't tested whether EXPORT unlinks the file
first if it exists.  I doubt it, though.

2) Less safe way with race condition under which there is a window of
opportunity for anyone to read/mangle the data:  SYSTEM off a chmod 0600 on
the file afterwards.

You're going to have to bear in mind that fP is doing its I/O as filepro
via EUID, and your SYSTEM of a chmod will be running as the UID, however.
Which point says that you need to start getting all your file operations
done by filepro, or you need to start using something like sudo, which
isn't a real optimal solution when you consider the commands you may be
placing in its allow list to run as filepro.  Give sudo access to mv or
cp and you can potentially kiss any filepro-owned file (including data
files and binaries) goodbye if you have a malicious user.  In this case,
what you want to do, since chmod will actually run as the same UID as the
external software that created the file, is let filepro read those files.
Unfortunately for ease of use but fortunately for security, most systems
now bar chown'ing files away from yourself, so there's not a great answer
here other than having filepro copy the file itself (this can be done
in very few lines of code), and then remove the original that the other
user owned.  None of which is very elegant, it's still subject to race
conditions, but it works for long-term storage.

When handling EXPORT, using internal I/O functions would work just fine.
When handling the other files generated by externals run under another UID,
this whole area is problematic.

All of which stems from the shell doing what shells should have done for
many years before bash took the initiative, wisely or unwisely [that's
a topic for a religious war...not going there].  Technically speaking,
their security model with bash is tighter.  However, the tighter you wind
security, the harder it is to work around some things.  The entire problem
is really a function of the design of fP, in which there is no single
daemon with which all clients interact, but rather a series of programs,
all of which run SUID.  That's why one doesn't run into this problem with
more recently designed databases.  (Which argument sounds familiar, and
is possibly the one valid point that Jeremy Anderson wrote about that
is hard to dispute.  Ignoring historical contexts and timelines, and
focusing strictly on the technical, the single-daemon model as a generic
implementation is a lot easier to securely interact with.)

HTH.  Luck!  :)

mark->