Oracle, to the best of my understanding, uses the model you describe (OS level security), but as an example, MySQL does not. There's something to be said for it, too: when I create a root user in MySQL, I don't necessarily want that user to log in (to Unix) as root.
--- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > Comments below. I know that the VA doesn't have separate user ids > for > each user at the operating system level, but I don't know why. > [Anyone > know?] > > In any case, best security practices today are not to have shared > user > ids, and in the context of medical practices which may not have the > same > level of physical access control as a VA facility, I would suggest > stronger access controls. > > -- Bhaskar > > On Fri, 2005-07-29 at 09:56 -0500, Mike Lieman wrote: > > > > > > On 7/29/05, K.S. Bhaskar <[EMAIL PROTECTED]> wrote: > > Mike -- > > > > I looked at the document. There's no need to create a > > separate gtm > > user. Each user can just login with his/her own user id. > > > > I thought that through, and decided I wanted the GT.M files owned > by a > > user other than root. 'oracle' owns the oracle files, 'mysql' own > the > > mysql files, 'qmail' owns the qmail files. > > [KSB] My recommendation is to create a user and a group for each > VistA > instance, i.e., if you have production instances for St. Mungo's > Hospital and the Azkaban Infirmary on your server, then create two > groups, azkaban and stmungos, and a user azkaban in the azkaban group > and a user stmungos in the stmungos group. These users will own the > database and journal files as well as the directories they are in, > and > processes with these userids will be used for operations (e.g., > backup) > but not normal VistA usage. As a further security precaution, you > can > permit someone to su to them, but prevent anyone logging in as users > azkaban or stmungos. Give each VistA user his/her own userid, > assigned > to the group where s/he practices. Special consultants affiliated > with > both institutions can belong to both groups. > > The database files, journal files, and directories would have > permissions set to be user and group writable, but neither readable > nor > writable by anyone else. > > Shared globals that are not normally updated, e.g., the National Drug > formulary, would be in a separate directory that is world readable, > but > writable by none. > > > > I'll *likely* have a single VistA user, since VistA itself has a > very > > robust user maintenance/signon model. ( And I expect most usage to > be > > with the Windows client... ). > > > > > > It may be helpful if you download the GT.M Acculturation live CD > from > > http://sourceforge.net/projects/sanchez-gtm and work > through > > the > > examples. > > > > Thanks for the link! I'll try to get to it over the weekend, but > no > > promises! > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September > 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
