Comments below. For clarity for others on the list: it's easy to deploy VistA on GT.M on Linux in the traditional model where everyone runs as a vista userid. The discussion is about deploying in a model where people run with individual userids.
--- Bhaskar On Mon, 2005-11-28 at 11:53 -0800, Greg Woodhouse wrote: > --- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > > > > > [KSB] Let me turn this around because you know more about VistA than > > I > > do. What do you see as not working if each user has his/her own UNIX > > userid? [Note that there may still be a user vista under which a > > nightly backup is launched under cron, or which owns processes that > > serve CPRS GUI clients that connect at a TCP port, etc. But regular > > users who login to the system would not use vista.] > > > > -- Bhaskar > > For starters, I think I was making an incorrect assumption. When you > spoke of users running VistA with their own uids, I had in mind a set > up where users would first login to an ordinary shell account (i.e., > one use bash, tcsh, or some such) and then enter VistA. Certainly, it's [KSB] My expectation is that for users who are not to have unrestricted shell access on the underlying operating system shell, when they login, their userid is configured to run a script of a few lines that turns off ^Z, traps interrupts with an exit, and runs VistA with an entry point of ^ZU. As soon as such a user exits VistA, s/he is logged off the system. > possible to have multiple user accounts that take the user directly to > VistA, but there are some complications. For starters, shoret of using > a mechanism like ACLs, you're pretty much left with group IDs to > control access to system resources (like printers), host files, etc. > That's not a problem unless, of course, you want to use the group for > something else. But you also need to ask what you would gain. Keep in [KSB] In most cases, group ids are sufficient to provide access to resources like printers. In the unlikely event tht ACLs are required, they are easy enough to set up. The general philosophy is that operating systems go to great lengths to implement access controls and other security mechanisms. Applications should use them. > mind that any actions performed through CPRS are not going to be > performed directly by the user signed in, but (at the system level) by > the Broker listener itself. The same considerations apply to HL7. Also, > don't forget that any queued (background) task will be performed under > the control of Task Manager, meaning that the process uid will be that > of the submanager, which will probably be a system user. In short, > while it would be nice to use OS level security for auditing purposes, > it doesn't actually reflect who it is that actually performs the > actions you want to audit. The user ID (DUZ) at the VistA level gives > you much more detailed information. Finally, there are gotchas to keep > in mind: If the user does have a shell account, can he or she run gtm > in direct mode using su or sudo (it's not just root)? [KSB] I agree that for actions performed through CPRS, the updates will be logged by user vista. In this case, presumably the GT.M journal files would presumably yield the real user id for audit purposes. Note, however, that someday (HIPAA-2? 8-]) it may make sense to enhance the CPRS GUI protocol and client so that the client provides the uid/gid for the server process (this would of course entail the client providing appropriate credentials). Apropos background Tasks, does Task Manager have the ability to fire up a task on demand to take care of a piece of work, rather than calling on a task from a pool of tasks? If it does, then that's how VistA should be deployed on GT.M, and in that case the tasks will have the userid of the user rather than the generic vista userid. Note that on UNIX/Linux, all users have shell accounts. But the system admin gets to specify what they can do when they log in. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
