Pseudo Device Driver example available?

[Richard J Maher]

Hi,

I have a client/server middleware package that, as part of its functions, will authorize network client application access to your VMS servers.

A small snippet of this code I have trimmed, massaged and attached to this post.

My dilema is that I have been reliably informed by HP employees that what I am doing is, in fact, the "wrong" approach and that I should be using a pseudo device driver for this purpose.

So if *anyone* has an example of such that fullfills the functions of the attached server code and (in following post) RTL code then that would be much appreciated.

I really want to get "on-message" with this!

Regards Richard Maher

PS. Most of the code you'll see functions very well in-situ but it's just been slapped together here for example's sake. Obviously the process should be a little bit more reluctant to die, but if we could concentrate on the pseudo-driver replacement/interface that would be just peachy!

[Richard J Maher]

Hi again,

And here is the User-Written System Service (RTL) code that allows a user with absolutely zero privileges to verify Username/Password access (within the confines of your code/application and the System Manager controlled access to the shareable image).

Think Rdb/SQL where you obviously can't install SQL$ with privs but yet have to somehow validate credentials when it comes to opening a database. You could: -

a) Call-out to another shareable(s) (an exercise that (on IA64) is architecturally guaranteed to cause you security problems if you're using C or calling sys$scan_intrusion (which calls lib$get_vm)) I wonder what rdb$cosip.exe does?

B) Do something very similar to what the attached code does.

Regards Richard Maher

PS. I'd normally stick another user-mode shareable between the UWSS and whoever will be the end-user, but this is just an example and I'm concentrating on that Pseudo-Device Driver horizon!

[Robert Gezelter]

Richard,

So I do not make an incorrect presumption, precisely what semantic issues where the "HP employees" referring to?

- Bob Gezelter, http://www.rlgsc.com

[Richard J Maher]

Hi Bob,

To quote from one of Stephen Hoffman's numerous(prolific)posts to comp.os.vms (and I may be paraphrasing a bit here :-)

. User-Written System Services are crap!
. The devil makes work for inner-mode code
. Using sys$output for a log file is crap!
. Image Initialization routines are crap!
. The Hoff prefers to use a Pseudo-Device Driver to solve all of these problems and more!

So can you see my dilema?

It's unimaginable that everyone out there has simply been ignoring Steve all these years so there simply must be a Plethora of these PDD examples available. (Maybe The Hoff could share one of his with us?)

That way the unbiased viewers could compare and contrast the methodologies and have a healthy debate about the pros and cons of each one.

I've put my code out there to start the ball rolling and am *happy* to be shown the fundamental design flaws.

Who's gonna champion the Apples?

Regards Richard Maher

PS. Not aimed at Bob but at the group at large. *PLEASE* do not reply with conjecture or theory of what you imagine, in a drug-induced haze, *could* be wrong with my example.

If you can *prove* something is wrong *and* you know what you're talking about then I am grateful for any input.

Sadly I've wasted too much time on Sunday's Experts from the ITRC already :-(

[Richard J Maher]

Oops! That's what happens when you rush, rush, rush.

Looks like I was imagining the lib$initialize routine being invoked in Exec Mode rather than user.

Have to go out, but will check this arvo and provide a new version if needed.

Cheers Richard Maher.

[Richard J Maher]

Sorry, had a First Communion, followed by a beautiful lunch at Matilda Bay, followed by an even more beautiful snooze on the couch! Not much got done :-)

I can easily change what's in the Auth_Init initialization routine to just another UWSS but I found something curious when I went looking for why I thought (on Alpha) that the init routines now get activated in Exec Mode and found the attached example.

If you look at this bit: -


.call_entry label=auth_init

movpsl r0
extzv #psl$v_curmod,#psl$s_curmod,r0,cur_mod
cmpl #psl$c_exec,cur_mod
bneq 20$

$exit_s code=#44

It certainly looks to me that it thinks it's in Exec Mode. Am I seeing things? Ok, so maybe I was extracting the processor mode the wrong way (seems to work on VAX as *not* Exec) so I stuck the $exit_s in there and it kills the process as well as the image. For my money this certainly smaks at Exec Mode behaviour!

If Auth_Init is not being invoked in Exec Mode then please tell me why not. If it is then why in my example a feq replies ago is it not?

Must still need more sleep.

Regards Richard Maher

[Ian Miller.]

for other people who may be following this.

An answer from cov is that a pseudo driver example can be found at

http://vmsone.com/~decuslib/vaxsig/vax88b2/addbook/

This directory contains the example ACPs and FIFO driver source code from the book, "VMS Advanced Device Driver Techniques" by Jamie Hanrahan and Lee Leahy.

[Robert Gezelter]

Richard,

I am in a bit of a hurry at this instant. I am have quite a few things to finish before I leave for Houston, where I will be speaking for the IEEE Computer Society on Friday and at the HP Technology Forum on Monday afternoon.

I will try to write something about your question. but it may be somewhat delayed.

- Bob Gezelter, http://www.rlgsc.com

[Richard J Maher]

Bob,

Me, I'm off down the pub with Boutros Boutros and Kofi so don't wait up :-)

Ian,

Thanks for at least describing the post in COV as *an* answer! (That would be analogous to me describing sys$examples:uwss*.* as *an* example of a UWSS) Although there appear to be a couple of "issues :-)" with my example, I think the richness of the code deserves a little more respect!

Anyway, the big man has all but committed to providing an complete authorization PDD example so let's just wait for that shall we?
Ya know? A COM file that I can just "at" like mine?

Cheers Richard

PS. I'm gonna try cluster/collect the lib$initialize stuff to see if that makes a difference, but I'm also off to less than exotic locals (Sydney) next week for that crazy Jackass TV of a ride that is the Rdb Tech Forum :-) Me and Bob are livin' on the edge!

PS. Is it true that David (Sir) Frost deliberately organized it so that Nelson Mandela stayed over his place on census night?

[Richard J Maher]

Hi again,

OK, finally had a chance to test things out and I was wrong about being wrong and I am, in fact, as brilliant as I always thought I was :-)

There is a grand total of one line that has to be changed in my first command file and that is: -

$ install replace auth_serv/priv=(tmpmbx,sysnam,sysprv,security,world)

I had forgotten WORLD privilege and as I do a $getjpi on the mailbox sender_pid that comes in pretty useful :-)

So, Ladies & Gentlemen, your UWSS initialization routines do in fact get invoked in EXEC mode on Alpha (and IA64)

I checked my Tier3/hotTIP code and found that it also raises privs before EXEC Mode channel mailbox I/O so this bollocks requirement to raise privs to do Exec Mode i/o on an Exec Mode channel appears to be down to the author of the Mailbox Driver being complete rubbish :-)

So where's Hoff's politically (if not functionally) correct Pseudo-Device Driver for username/password authentication written in C? ***BRING IT ON***!!!

Anyway, I'm off to address the General Assembly on how IT can influence Global Warming while feeding Africa. See ya!

Regards Richard Maher

PS. If anyone's waiting for the cliquey mutual-admiration society that's sadly running things round here to actually tell us why the Init Routine $setprvs are needed (except the last one) and yet the UWSS and rundown routines are not, then I wouldn't hold your breath!

There is a collective noun for these people and it rhymes with Bankers! (Still can't say too much as I don't want to give some Nazi another excuse for deleting a post.)

Anyway, looks like everyone's off chasing Dave Sneddon's System Crasher of a patch. It's not like you can chase down every excentricity or foible in every dodgy IT shop. $DISMOUNT/NOUNLOAD I mean how exotic is that? There's just no way that regression testing can be expected to catch everything!

[Richard J Maher]

Hi,

The great news is you will no longer find a single HP employee to waste your time with fanciful notions of pseudo-device drivers. The beast has been smited! A stake driven thru his heart means that no more will the happy village be descended upon by the tyranny of that dark shadow.

Yes children: -

. User-Written System Services are great!
. Inner-mode code is a security plus not a minus!
. Using sys$output for a log file is perfectly reasonable!
. Image Initialization routines are the mut's nuts!
. Pseudo-Device Drivers are evidently only the figment of someone's twisted imagination!
. MACRO-32 is good! And what's more, the *only* safe language for /noPROTECTed UWSS's on Itanium!
. VMSINSTAL is a fabulous kitting tool that simply ain't broke!

Yes, go out, be happy, enjoy VMS once more!

Now, faced with the original requirement in this thread, and IMHO, User-Written System Services (similar to those displayed in my attached examples) are definitely the way to go.

Also, below is a post of mine from comp.os.vms that contains some useful IMHO information about how mailbox (most device) protection works and what could be wrong with it. Please let me know if you have any corrections.

Regards Richard Maher

PS. If there is still anyone out there with a lot of time on their hands then I'm still curious to what a PDD example of a User-Authorization device-driver would look like. Any takers?

Mailbox protection issues
-------------------------

You may recall that, a few weeks back, I was asking questions about mailbox
protection related issues with inner-mode code and why sometimes my (non
system) EXEC mode code had to "up" privs with SYSPRV and other times it
didn't, when doing i/o to a mailbox that had (s:rwlp,o,g,w). At that time I
was unable to find anyone who had a clue about what they were talking about,
so I've finally got around to investigating what was going on and this is my
best guess. (If there is anyone in this newsgroup that can tell their arse
from their elbow when it comes to VMS device security checking then please
chime in will any facts relevant to correct coding.)

Maybe it's in the fine manuals? I couldn't find it. If you have a pointer
please pass it on. If not, I sure hope this helps someone else in the
future.

1) Anyone can assign a channel to a mailbox even if they have absolutely no
privileges and no SOGW or ACL access to the device
2) Access rights tests are deferred till $QIO time and ganularity is
dependant on the function code
3) Access is only checked the first time for each appropriate function codes
(A record of the checks already made is in kept in the ccb$ll_sts field of
the Channel Connect Block. ccb$v_readchkdon, writechkdon, logchkdon etc)

If this is true then that would certainly explain why I had to $setprv
(sysprv) before the initial io$_writevblk or io$_setmode but subsequently
everything was peachy. I assume the check is only done once as an
optimization, but then surely it would also make sense to have some sort of
io$_accesscheck so that the programmer could get all his checking done up
front at initialization time and not have to have a $setprv in his main
routine or in a loop?

I can understand why these checks can't be done at $assign time as there is
just not enough infomation there to describe everything that you may wish to
do on a channel in the future, but one thing *is* known and that is if you
don'y have "L" access to a mailbox then you can't do *anything* with it, and
SYS$ASSIGN (or EXE$CHKPRO_INT or whatever) should *not* assign a channel to
that device. It is just plain wrong!

What if I have a io$_setmode!io$m_waitforreader on a mailbox that has
(S:RWLP,O,W,G) protection and some idiot comes up and does a $OPEN/READ DOS
_MBA123: Does my code fire up and say "Bewdy! Our partner's there now" and
not some snotty nosed hacker? What if I rely on my temporary mailboxes dying
after all *my* channels are deassigned only to find that a third party has
assigned a channel to it and is keeping it alive? They don't have access to
my Logical Name tables but they are sure as hell stopping my $CREMBX from
creating a *new* mailbox and changing the logical name!

BTW. Why does RMS give you a NOPRIV error when you close the channel?

Did everyone else know that changing the protection on a mailbox after
channels have been assigned may or may not have the desired results? Say you
wanted to limit writers to only SYSTEM users for a while; if a WORLD or
GROUP user already done i/o on there channel they'd never see the change in
protection.

Anyway, in my case, I couldn't see how to *automatically (without $setprv)*
take advantage of being in Exec-Mode on an Exec-Mode channel. I can make
sense that you still want the checks performed. (There is a io$m_trusted
modifier that can be used to avoid the probes if your using Exec-Mode iosb
memory etc) And my channel *is* protected against User-Mode interference
which is the whole point.

Regards Richard Maher