Re: fis-gtm

["Bhaskar, K.S" <ks.bhaskar@fisglobal.com>]

Title: Re: fis-gtm

On 07/26/2011 02:17 AM, Karsten Hilbert wrote:

Hi Bhaskar,

> [KSB2] Historically, GT.M was installed as owned by user and group bin. 
> Over the years (GT.M first went into production in 1986) and over the
> POSIX platforms to which it has been ported (including GNU/Linux,
> proprietary UNIXes and z/OS), there is no single standard user and group
> id that the standard installation script (configure) can use (not all
> platforms have root, and not all platforms have 0 as the super user).  To
> keep our maintenance costs low, we aim for maximum code commonality
> across the platforms.

I think much of the confusion (at least mine) stems from the fact that
most people seem to assume that something as mature as gt.m must be
running a system-wide server process to which clients connect -- like
PostgreSQL does.

If I understand you correctly this is not the case ?   GT.M is run by
each and every user that needs it to access a database ?

This latter case would be like SQLite works and, of course, needs no
special systemwide user id *to run under* (like postgres:postgres for
PostgreSQL). The former would suitably use a dedicated user to *run*
the server under (not *own* the server binaries). Both need a user id
to own the binaries but that can suitable be root:root.

Please destroy my confusion !

[KSB3] OF course!  Sorry, I am so close to GT.M that I may miss the fact that what is obvious to me may not be obvious to others.

GT.M has no database daemon.  GT.M processes operate with normal user ids and group memberships, and a process is able to access a database file only if its user id and group membership has access to the database file as determined by the database file's user / group / world permissions.  Details are in the security philosophy document (http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_Security_Philosophy.html is the URL; the way to always access current GT.M documentation is to go to http://fis-gtm.com and click on the User Documentation tab).

The first process to open a database file sets up the interprocess communication control structures (e.g., shared memory) needed for multi-process / multi-user access.  The last process to close it cleans up.

Regards
-- Bhaskar

-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________