HP3000-L Archives

October 2004, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Emerson, Tom" <[log in to unmask]>
Reply To:
Emerson, Tom
Date:
Wed, 13 Oct 2004 09:13:03 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (15 lines)
> -----Original Message-----
> Behalf Of Stuart Diamond
> 
> Is there a way to lock out a specific user so that they can 
> not get into Query??

Other users have commented on various methods [lockwords, ACD's, renameing, etc.] and have pointed out the various "workarounds" that a determined user might employ  to circumvent your "security measure(s)".  One that hasn't been mentioned and is specific to Query is to set the "subsystem lockout" bit in the database -- basically, it is a flag setting in the database itself that Query will recognize and honor [or, at least, that is what I have been lead to believe...]

The downside: this locks EVERYONE out of using this tool, and DOESN'T lock anyone out who uses a hand-built and/or hacked version that simply ignores this setting.

There is also a non-technical solution: make it a POLICY that "query is not to be used on production systems(*) -- the penalty for ignoring this directive can and will include termination of employment".   (*) with whatever caveats and overrides are neccessary to enable YOU to still use of Query, such as an "emergency" situation when a coding error in your application writes incorrect values to some dataset...

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2