OS-9/OSK Answers! by Joel Mathew Hegberg
October 1994 issue


Last month, you may have noticed pages 15 and 16 reversed (at least it was in my issue). Hope that did not confuse many people. Like Rick Ulland mentioned in his last article, I can be a little sneaky! Rick's always has something interesting to talk about. Let me check... yep, Rick's written yet another great column over on page [xx], so be sure to check it out -- AFTER you've read my column, of course!

This month, we start out with a letter regarding OS-9/68000 security. I encourage all OS-9/68000 users to set up their systems as multi-user systems, since the software is included. There are many times this benefits you in the long-run.


Hello, 68'micros!

Ulland's 68micro OS-9 security discussion came just as I was thrashing about. Noting references to cc3 I think he was not looking os9/68k. I'm on MM1 and had began thinking I should protect all the stuff in there.

My original startup opened several windows with preset DIRs. Thinking these would present sneak paths around the login I moved them to a script file to be used after logon. After changing startup file to one incorporating "login" I notice that three CRs after "Username?" gets me back to shell prompt without needing to enter name or password. Of course if I do enter name & password then the sequence shows me the OS9 welcome field from SYS/motd (where I put a note about the scriptfile to set up my preferred windows). But when login fails and falls thru to original startup shell prompt I can still use my scriptfile. (The original shell prompt is $, whereas my password file gives $: .) Indeed, both password AND name can be nothing. The system is wide open.

So what have I missed? Is there some way to unboot or unlink a useful file and require rebooting in case the login falls thru? Is there a better login module or patch? I tried the format in os9 manual-- login [name] [,] [password] . They are indeed optional. ex also seems optional.

startup file:
-------------
iniz d0 d1;load runb cls unlink syscall color more display
loadbuffs
chd /dd;chx /dd/cmds
merge sys/stdfont_01.fnt sys/stdfont_02.fnt
xmode /t0 baud=2400;legi;datn
ex login<>>>/term

-- Fran Walters


Dear Fran,

Thanks for writing. As it turns out, you are half right. In setting up security on your system, you need to run the "login" program to let the user enter their name and password. As you point out, there needs to be something to re-run the "login" program when it exits after 3 invalid attempts.

The program that does this is "tsmon", which is actually the program you should be running from your startup script file instead of "login". tsmon (time-sharing monitor) automatically runs "login" when the [RETURN] key is pressed in a window or on a terminal. When "login" dies, it waits for another [RETURN] key and runs it again.

Even better, tsmon can monitor more than one window/terminal at a time, making multiple login windows/terminals a breeze! In my startup script file, I open two windows from which I can log in from. The very last line of the file is:

ex tsmon -p /term /w1

This runs tsmon (without an underlying shell), allowing logins from /term and /w1 devices. tsmon takes care of both devices automatically! And there is no way from someone to drop out of tsmon so the system is rather secure. The option '-p' prints out an "online" message to all specified devices to let users know they can log in.

Hope that helps, Fran! Let me know if you have any other problems!


Ted Jaeger has sent in an example on how to use BASIC's TYPE command to create a new datatype, which makes the creation of graphical objects (in this case, K-Windows) very easy. Instead of a series of PUT commands, using this technique you can merely use a single PUT #1,button command. Ted also notes that this method is much faster as well, requiring fewer i/o calls to the operating system.

The program could easily be ported to C, but with the availability of the cgfx.l graphics library for free, there really is no need. The BASIC "TYPE" command is very similar to the C "typedef struct" concept. My thanks to Ted!

Listing #1: makebutton.bas
==========================

PROCEDURE makebutton
(* how handy is TYPE !!
(* Ted Jaeger -- June 29, 1994

(* here we use TYPE to establish
(* a graphics object--a button--
(* by collecting all its parts into
(* one variable
TYPE buttonparts= startpoint(6), clr1(3), frame(6), locate(6), clr2(3), shade1(6), shade2(6), clr3(3), shade3(6), shade4(6), sync(1):BYTE
(* The "sync" byte is for K-Windows...
(* sometimes it is needed to get K-Windows
(* back in sync.  It has a value of $00.
DIM button:buttonparts
DIM downbutton:buttonparts

(* we also use it in a more conventional
(* way -- to define a new variable to function
(* as a registrar mask and let us
(* do system calls in BASIC
TYPE registers=d(8),a(8),pc:INTEGER
DIM regs:registers

(* an array to quickly change
(* foreground color
DIM fclr(3):BYTE
fclr(1)=$1b
fclr(2)=$32

DIM char:STRING[1]
DIM callcode:INTEGER

(* now lets load the button variable
(* with the escape sequences to draw it
button.startpoint(1)=$1b
button.startpoint(2)=$40
button.startpoint(3)=$01
button.startpoint(4)=$09
button.startpoint(5)=$00
button.startpoint(6)=$63
button.clr1(1)=$1b
button.clr1(2)=$32
button.clr1(3)=$00
button.frame(1)=$1b
button.frame(2)=$48
button.frame(3)=$01
button.frame(4)=$48
button.frame(5)=$00
button.frame(6)=$73
button.locate(1)=$1b
button.locate(2)=$40
button.locate(3)=$01
button.locate(4)=$47
button.locate(5)=$00
button.locate(6)=$64
button.clr2(1)=$1b
button.clr2(2)=$32
button.clr2(3)=$0f
button.shade1(1)=$1b
button.shade1(2)=$46
button.shade1(3)=$01
button.shade1(4)=$0b
button.shade1(5)=$00
button.shade1(6)=$64
button.shade2(1)=$1b
button.shade2(2)=$46
button.shade2(3)=$01
button.shade2(4)=$0b
button.shade2(5)=$00
button.shade2(6)=$72
button.clr3(1)=$1b
button.clr3(2)=$32
button.clr3(3)=$01
button.shade3(1)=$1b
button.shade3(2)=$46
button.shade3(3)=$01
button.shade3(4)=$47
button.shade3(5)=$00
button.shade3(6)=$72
button.shade4(1)=$1b
button.shade4(2)=$46
button.shade4(3)=$01
button.shade4(4)=$47
button.shade4(5)=$00
button.shade4(6)=$64
button.sync(1)=$00

(* now we have the button constructed
(* lets make downbutton similar
downbutton=button
(* but different shading
downbutton.clr2(3)=$01
downbutton.clr3(3)=$0f

(* lets display button on a lite gray background
(* with no text cursor
SHELL "display 1b 33 0e 05 20 "
(* no echoing
SHELL "tmode noecho"
(* clear screen
PRINT CHR$(12)

PRINT CHR$(2); CHR$(54); CHR$(42); "Press a key to see button move"

(* all we have to do to produce
(* the button is
PUT #1,button
PRINT CHR$(2); CHR$(67); CHR$(45); "Quit"

(* now lets make it move when
(* user strikes a key
GET #0,char

fclr(3)=$0f
PUT #1,fclr
PUT #1,downbutton
PRINT CHR$(2); CHR$(67); CHR$(45); "Quit"

(* sleep for a bit
(* so user can see button in down position
callcode=$0a
regs.d(1)=$64
RUN syscall(callcode,regs)

(* now replace the up button
fclr(3)=$00
PUT #1,fclr
PUT #1,button
PRINT CHR$(2); CHR$(67); CHR$(45); "Quit"

(* put cursor back
SHELL "display 05 21"
(* turn echo back on
SHELL "tmode echo"

Well, that's all for this month. Next month I hope to start exploring the world of termcap! Stay tuned for some exciting OS-9 Answers, and as always, if you have something of interest you think others would benefit from, by all means send it in! Stay happy and healthy.

* THE END *