× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



midrange-l-request@xxxxxxxxxxxx wrote:

>   5. Eliminating command line access (Adam Lang)
>
>What is the best way to restrict a user form accessing the command line and
>only being able to use menus?

Adam:

Hard to say. How do users access your system?

>From directly cabled terminals? Then give them an initial program that never 
>presents a command-line and set their initial menu to *SIGNOFF. Also set them 
>as LMTCPB(*YES) to prevent bypassing those via a signon screen. Note that 
>LMTCPB(*YES) does not technically restrict users from using command lines; 
>instead, it restricts them from executing commands with the  ALWLMTUSR(*NO) 
>attribute on a command line. Then, shutdown your network servers such as the 
>*RMTCMD host server and FTP TCP/IP server, among others, so commands can't be 
>sent from PCs or other systems.

Do they access via emulation on PCs? Hmmm... all the above is still good, but 
probably impractical because your various network servers are probably being 
used in numerous ways, not just telnet. Now you'll probably also have to do 
something like placing exit programs on all the various exit points for servers 
that implement remote command functions. The exit programs will have some kind 
of business rules that you'll define to choose when a request is allowed or 
rejected. Unfortunately, some servers will check LMTCPB() but merely pass back 
a yes/no flag to the client; it's up to the client to decide what to do at that 
point. Others will respect the attribute directly.

Which brings up -- Do they access your system via some client/server 
application? Then maybe it won't matter what you do. It will depend on how the 
C/S app handles remote commands if it provides such a function. (Some do, 
although you're not always aware of it.) Any chance an SQL statement could be 
sent in via a browser session? one that does an SQL CALL to QCMDEXC?

Overall, I suppose the real question is "Why restrict command line access?" If 
your users don't have the authority to do some damaging action in the first 
place, a command line won't make a difference -- the action can probably be 
done elsewhere. If they do have too much authority, then maybe there are users 
who can undo anything you put in their way.

Quite a few have gotten wise to this whole "search google for how to do it" 
thing. And if you put a couple of those users together during a boring coffee 
break, anything can happen. Oddly enough, most users nowadays have less 
knowledge about command lines than they do about how to format complex URLs in 
a browser.

Same old advice as has been valid forever -- auditing, backups, journalling, 
object/resource security, security policies, etc., etc. If the system is solid, 
command lines are no big deal. If that's impractical, it'll almost certainly be 
cheaper to bring in 3rd-party packages to help.

Tom Liotta

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
Introducing the New Netscape Internet Service. 
Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need. 

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.