Erik Vistica wrote:
> Good news is, I get the same results in my tests. :-)
> Bad news is, I get the same results in my tests. :-(
well at least i'm not completely insane :-) partially...but not completely
:-)
> The examples in the System Startup, Configuration, and Shutdown
> Reference Manual show hardcoded passwords.
(yeah, i saw that too....not exactly heart-warming....)
> So, it seems that it is more of a 'feature', er, 'known limitation?'
> rather than a bug. I agree that leaving passwords in a file in PUB.SYS
> is undesirable. The RCAN addresses this by suggesting the use of ALTSEC
> after editing SYSSTART. While that does solve it, I personally would
> forget.
ummm, someone mentioned that changing the sysstart file with editor would
undo the security modifications. knowing editor, that's probably true (but
i didn't test it). however, a certain well-known editor from a certain
canadian company (starts with an 'r' :-) leaves the security mods in place
(i did test that). someone else also mentioned placing an 'altsec' command
in the sysstart file. i don't think you can do that...but doing an altsec
in some start-up job stream is probably good insurance. and given this
morning's question about 'why didn't my sysstart file get executed' (ummm,
because you didn't blindfold it first? (hehehe))....it may be a good
practice to also do an 'altfile...;owner=' as well.
> I like the suggestion that Russ Smith made:
> > How about this? If your console is in a secure location and your SYS
> > account (and possibly OPERATOR.SYS userid, as well) is passworded, why
> > not modify your logon UDC to test for HPLDEVIN=20, HPJOBTYPE=S and
> > HPJOBNUM=1 to bypass the need for a session name. If you have the
> > ranges for SESSNUM (use SETCOUNTER to set iterations) set to preclude
> > session number 1, this should be secure.
yes, this is also a good suggestion. thanks for looking into this
erik! - d
--
Donna Garverick Sr. System Programmer
925-210-6631 [log in to unmask]
>>>MY opinions, not Longs Drug Stores'<<<
|
