The Login Process

The Login Process

Top  Previous  Next


There are two stages to login; user authentication and process initialisation.



User Authentication


On Windows, users connecting to QM via a network must enter a valid Windows user name and password. The new process runs as that user and with the associated access permissions.


QM implements a further layer of security on top of the Windows authentication by maintaining a register of user names allowed to use QM. A user name may be added to this register using the CREATE.USER or ADMIN.USER commands. The register entry determines:

1.whether the user is allowed to use QM at all. This check can be suppressed using the SECURITY command.

2.whether the user is to be granted administrator rights within QM.

3.the name of the account that the user should start in. If no account is specified, a prompt is displayed for the account name.

4.restrictions on which accounts they may access.


If security has been turned off and the user name does not appear in the user register, the user runs without administrator rights and an account name prompt is displayed.



On USB installations of QM, the above mechanism is extended such that QM performs the user name and password validation using its own internal user register. The newly created process runs with the Windows user name and access permissions of the user that started the QMUSBSrvr process.



On other platforms, users connecting to QM via a network usually open telnet sessions as normal users and then enter QM, perhaps automatically via their profile script. It is, however, possible to connect directly to QM in which case the security mechanisms described above for Windows apply unless the qmlnxd process is running as a non-root user. In this situation, the user name must have been defined using the CREATE.USER or ADMIN.USER commands



Process Initialisation


When a user successfully enters an interactive QM session, the following steps occur:


1.For users entering QM directly from a network connection, QM attempts to determine the terminal type by use of telnet negotiation commands. If the emulator in use does not support these, QM looks for an environment variable named TERM and, if this is found, uses it to set the default terminal type. If this also fails, vt100 is used by default.


For QMConsole users on Windows, the terminal type is set to qmterm. For users entering QM from an operating command prompt on other platforms, QM looks for an environment variable named TERM and, if this is found, uses it to set the default terminal type. If this fails, vt100 is used by default.


The terminal type can be changed later from within QM using the TERM command. When using AccuTerm, it is strongly recommended that the terminal types with the -at suffix (e.g. vt220-at) are used as these enable AccuTerm specific features such as the screen switching required for the full screen mode of the QMBasic debugger.


2.QM then looks for environment variables named LINES and COLUMNS and, if found and valid, uses these to set the initial size of the terminal window. When using a QMConsole session on Windows, the displayed window will be adjusted to be this size. On other connections, it is the user's responsibility to ensure that the terminal emulator screen dimensions match those expected by QM.


3.The system looks in the QMSYS account VOC file to find a paragraph named MASTER.LOGIN and, if this exists, executes it. This paragraph can be used for system wide initialisation such as setting European date format or standard printer associations.


4.The system checks in the user's account VOC file to find an executable (menu, paragraph, sentence, verb) item named LOGIN and, if this exists, executes it. The LOGIN item is typically used to perform account specific initialisation and the enter the application. Note that this happens for all QM processes, including phantoms and QMClient sessions. To exit from the LOGIN paragraph for a phantom process, insert a line

IF @TTY = 'phantom' THEN STOP

at the relevant point in the paragraph. For a QMClient session, test for 'vbsrvr'. See @TTY for more details.


Some other multivalue products look for an item named the same as the user's login id. This can be emulated on QM by creating a LOGIN item that is simply

1: S

2: <<@LOGNAME>>


5.The break key is enabled. By running the MASTER.LOGIN and LOGIN paragraphs with the break key disabled, the user cannot quit out of any security checking done in these paragraphs. If a LOGIN paragraph is used to start the application, it may be necessary to enable the break key at this stage by including a BREAK ON command.


Step 4 above is also executed when the LOGTO command is used to move to a new account.



User specific process initialisation can be performed by testing the content of the @LOGNAME variable in the MASTER.LOGIN or LOGIN paragraphs. For example,