Virtual memory storage files are Windows files that mvBase uses for data space (for example, mvBase.000, mvBase.001, etc.). These files may be contained on more than one network drive.
Virtual memory storage files must remain accessible to the mvBase Server system(s) and administrator(s), but you may wish to protect such files from certain or all other users.
IMPORTANT |
Only an authorized user with administrator rights can create, resize or delete a valid virtual memory storage file via the mvBase Server. However, without proper Windows security implemented, it is possible for a Windows network user who doesn’t even have mvBase installed to access, delete, copy or rename virtual memory storage files from local or remote systems. This is the case for most Windows-based applications. |
Protection of virtual memory storage files on the network entails this combination of options, not all of which are available in every circumstance:
The drive on which a file is located may be password-protected and/or have very specific access granted according to User-Name (Read-Only or Full).
The directory on which a file is located may be password-protected and/or have very specific access granted according to User-Name (Read-Only or Full). This protects the directory while allowing general user access to the rest of the drive.
Finally, the virtual memory storage file itself may have very specific access granted by User-Name (Read-Only or Full). This protects the file while allowing general user access to both the drive and the directory on (or in) which the file is located.
Using Windows Passwords, Permissions and Access Types
When configuring security for virtual memory storage files, you need to determine who (which Passwords or which User-Names, or both) may access, create, delete, copy, rename or resize such files in Windows. At a minimum (and perhaps also at a maximum), you must allow authorized administrators who start and run the mvBase Server to make a connection with these system drives, normally during network logon.
NOTE |
Restricting a user’s access to a virtual memory storage file from Windows does not automatically restrict that user’s access from within the MultiValue environment. |
Perform these steps to implement restricted security for virtual memory storage files when necessary. Administrator rights are required.
Navigate to the system on which the virtual memory storage file is located via Windows Explorer.
Determine if you want to restrict access to the drive, the directory, or the file alone, and display the appropriate level within Windows Explorer.
Select the drive, directory or file with the right mouse button, and select Properties (or highlight the object, and select File, then Properties in the pull-down menu).
Proceed to define Sharing, Permissions, or Security, depending on which option(s) your version of Windows allow(s). This will mean defining either the Access Type according to User-Name or Password, or both.
If your version of Windows does not allow specific password protection, you may still define Permissions according to User-Name.
Finally, you may wish to use a password-protected screen saver in order to protect a system which must remain running in your absence.
NOTE |
Screen savers have been known to consume large amounts of system resources on Windows systems. Implement screen savers carefully on such systems, and monitor system activity closely after implementing a screen saver for the first time. |
Select Start from the Windows Desktop.
Select Settings.
Select Control Panel.
Select Display.
Select the Screen Saver tab.
Choose a screen saver type, and the Password Protected option activates.
Select the Password Protected option, define the password, and define the activation time.
Select OK.
NOTE |
In addition to protecting virtual memory storage files within Windows, you may also need to protect the contents of virtual memory storage files from within the mvBase (MultiValue) environment. This is achieved by defining user accounts and their system privilege levels (SYS0-SYS3). See Implementing MultiValue Security for additional information. |
How Implementation Affects Network Behavior
When properly implemented, this security measure described above affects network behavior in the following ways:
When the mvBase administrator starts Windows on the mvBase Server system, Windows requires entry of the proper User-Name, Password and Domain to get logged on to the network (this should be a standard practice of Windows network administration).
The pertinent Windows domain then verifies this input, and systematically opens up the network to the mvBase administrator who is logging on.
When the logon process arrives at the password- protected drive and/or directory, the system prompts the administrator for the proper password (if the drive/directory password differs from the network logon password).
When a non-authorized user attempts to access the password-protected drive or directory over the network, an Access Denied message displays.
Note that with proper sharing, authorized mvBase clients may now connect to the mvBase Server, and access the contents of its virtual memory storage files (wherever they are located). However, these clients may not access the virtual memory storage file outside of mvBase, as the following figure illustrates.
Also note that the mvBase Server system normally has at least one virtual memory storage file on the local system. Thus, to allow remote users to logon to the Server system, and yet be denied network access to this file, the file itself must be hidden or password-protected from within Windows.
This diagram illustrates the selective sharing of network drives that contain one or more virtual memory storage files. System A shares its drive C only with AdminX, an administrator who logs on System B. However, a Telnet client from System C can still access the contents of the virtual memory storage file via System B without being able to delete that file outside of mvBase.
See Also