Bhaskar;

   I am getting to this question a little late, but there are good reasons
for doing things this way for the VA.  Over the years, we have run on a
number of platforms and the most consistant means of maintaining the user
population was to drop the production user diretly into our internal MUMPS
environment as quickly as possible and not letting the users at the
operating system.  From the MUMPS level, the user is using the system at the
CHUI (CHaracter User Interface) level.  It is almost impossible for a
malicious user to load anything executable (it can be done with some very
clever code, but that would be very difficult and rare).

   Also the interface with different operating systems can be very
confusing.  Not forcing the users to use the local OS, they get everything
done in the VistA MUMPS environment which is more consistant between the
different implementations.

----- Original Message -----
From: "K.S. Bhaskar" <[EMAIL PROTECTED]>
To: <hardhats-members@lists.sourceforge.net>
Sent: Friday, July 29, 2005 8:31 AM
Subject: Re: [Hardhats-members] You must have a valid DUZ!


> 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
>
>




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members

Reply via email to