[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

378.0. "client/server" by BDWISR::HEAFEY (Wherever you go, there you are...) Fri Mar 10 1989 16:41

Hello all,

two questions:

1) I work for an IS group that is trying to come up with a strategy around
client/server relationships and one of our concerns is controlling where
a user can start an application. Another words, I don't want user A utilizing 
user B's workstation as a client. Is there any means to accomplish this today?

2) My other concern is limiting each user to a X number of processes per
client. 

Any help would be appreciated,
Dave H.

T.RTitleUserPersonal
Name
DateLines
378.1MU::PORTERwhat's in a name?Fri Mar 10 1989 21:5830
    You might have got your terminology backwards.
    
    The server is the thing with the display (the VAXstation hardware).
    A client is any application program.
    
    If this sounds backwards, consider that it's really the same 
    way round as "terminal server" !
    
    --
    
    OK, with that straightened out:
    
    (1)  Limiting access to servers (i.e. to VAXstations)
    
         No problem.  Each server has to have a list of node::user
         pairs for permitted clients.  If you're not authorized, you
         can't create windows on that server.   
    
         The authorization is set up by a customization mechanism
         under the session manager (thus it is specific to the logged-on
         user, if you happen to share one VAXstation between several
         people).
    
    (2)  Limiting the number of processes on the client machine.
    
         Since you essentially have to log in a process on the client
         in order to run an application, this is subject to the normal
         resource usage rules on the client machine.
    

378.2Another wayBDWISR::HEAFEYWherever you go, there you are...Mon Mar 13 1989 08:1525
Thank you for the explanation but, I understand the terminology. 
That was probably unclear from my base note. I'll put the question(s) another
way.

1) In a cluster with a common authorization file, what's to prevent me from
creating a process on your station (set host, detached process, batch, etc...)
and doing something like the following:

	$ SET DISPLAY/CREATE/NODE=MYNODE
	$ RUN SYS$SYSTEM:DECW$MAIL

This would utilize your workstation as a CLIENT and send all output to 
MYNODE (as long as I had authorized it). For batch this could be prevented
by ACL's of setting ownership on batch queue's but, that doesn't address the
set host or the detached method. What I'm looking for is a way to tell the
users that such and such nodes are the clients that you can utilize and I
also want to be able to enforce it.


2) I need a way to allocate X number of processes per user on a given CLIENT
and not allow them to start more.

Thanks,
Dave H.

378.3I don't get itJAMMER::JACKMarty JackTue Mar 14 1989 10:565
    In a cluster with a common authorization file, there's nothing to
    prevent SET HOST from one cluster member to another in a non DECwindows
    environment.  DECwindows has no more or less controls than VMS already
    provides.