NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/os/vms/17502

Internet Message Format | 1992-11-05 | 5.9 KB

Path: sparky!uunet!portal!cup.portal.com!Chris_F_Chiesa
From: [e-mail]
Newsgroups: comp.os.vms
Subject: Q: Homegrown COPY? FAQ?
Message-ID: <[e-mail]>
Date: Thu,  5 Nov 92 06:29:45 PDT
Organization: The Portal System (TM)
References: <[e-mail]> <bjVRf?[e-mail]>
Lines: 93

Hi Gang...

  I'm getting embroiled in a programming project that I'm almost certain has
to be fairly common, if not actually a VMS FAQ.  Namely, writing something to
emulate VMS COPY, with local extensions.  Has anybody done such a thing?  Is
there anything available for FTP?  Anything on a DECUS tape?  If so, stop
reading right here and write me mail.  If not, read on and I'll tell you what
I've tried, why it doesn't satisfy me, and what I'm thinking of trying next,
and THEN write me and tell me what I've overlooked or haven't thought of.

  Basically, I want to allow non-privileged users to copy files to which the
existing baseline VMS protections/ACLs don't allow them access, subject to
"permissions" "granted" by the owners of the files.  VMS protections/ACLs could
probably do the job IF they could be made to take effect, and expire (and the
corresponding ACL disappear from the file), at predetermined dates-and-times.)


  My current concept, still far from final, is a "privileged COPY.EXE" that can
copy any file, but which refers to a database of "which files are copiable by
holders of which identifiers during which time periods" in order to determine
whether to go ahead and perform any given request.  A separate utility will
manage the permission-granting database itself.  (I also face a number of
problems in figuring out how to handle permission-specifications which include
wildcards: do I resolve them into the list of files matching the spec at
"permission granting time," or at "copy-attempt time?"  Either way I have to be
able to take a copy-attempt file specification and search the database for any
and all records, including individual and possibly-overlapping wildcard specs,
which might permit a copy of that particular file.  I'm working with plain ol'
indexed files (I don't know anything about the supposed bundled interface to
Rdb -- is there info available?).)

  Ideally I'd like to tack my own copy-attempt-permitting-or-rejecting front
end onto the existing VMS "COPY.EXE" image, and install the result with READALL
privilege.  (I'm aware of the issues surrounding the writing of code to be
installed with privileges; I've followed and downloaded the discussions here.)
This would let me support all of COPY's file-selection qualifiers (/EXCLUDE,
/SINCE, /UNTIL, et al) without having to parse and process them myself.  A
posting here a couple of years ago gave the outlines of a technique for using
unsupported/undocumented system service $IMGACT to "merge another executable
image into your program's address space, and call that merged image as a
subroutine"; I believe the author and his company had put their own front ends
onto DELETE, DIRECTORY, etc.  I've successfully used the described technique
to merge one small "test" program into another and call it, but the program-
being-merged must not contain statically-declared address data because those
declared references apparently DON'T get fixed-up to account for the address
where the merged image actually winds up.  (It appears that address references
in executable code get fixed up, but references in declared data DON'T.  How
does one get around that?  Declare one's data psect as position-independent
when writing the original source code?  Hmmm.  How does the image activator
NORMALLY ensure that static declarations "actually point to where they
should?" Anyway, when the image being merged is COPY.EXE, the call-as-a-
subroutine fails because COPY contains static descriptor declarations that
don't get fixed up properly.)  It's probably a good thing this DIDN'T work,
because if it DID I would be tempted to use it even though it's highly
unsupported.

  Barring use of actual COPY.EXE, I next thought I vaguely remembered a
"LIB$COPY_FILE" RTL routine!  Yeah, right.  As you know, there is no such
animal.  Digital recommends using callable CONVERT, which is a poor substitute
for the functionality of the VMS COPY command: files actually "get converted,"
which isn't always (in fact, in my case, usually ISN'T) a good thing, and you
can't use wildcard specifications at all.  I have my own reasons for preferring
$QIO over RMS, too.  Callable CONVERT might be usable as a feeble, poor man's
solution to my problem, but--- EEEEEEEEeeeeeeeewwwwwww....

  Some other solutions I've thought of but haven't tried yet:

  * Writing an in-house equivalent to the mythical LIB$COPY_FILE.  Would
    seem to involve declaring and copying an uncomfortably large number of
    data structures, either RMS or QIO-ACP, to obtain and propagate file
    attributes information, even if I use $QIO to actually copy the file
    contents.

  * Implementing my project as a client which communicates with a detached
    server process running a DCL command procedure which verifies the client
    commands and then issues actual VMS COPY commands.  Has the advantage
    that it uses "real VMS COPY," and can therefore support the full normal
    behavior of same.  Has the disadvantage that now I have to deal with
    security-of-interprocess-communication issues.  What's the most secure
    way to have these things talk to each other?  Mailboxes?  Shared global
    sections?  Lock manager?

  It is at this point that I solicit any and all suggestions or discussions
from this newsgroup.  Tell me what I've overlooked, or what products or PD
wares already exist, or which of my possible options is best (or how to make
$IMGACT (I'm following the $IMGACT call with a call to $IMGFIX, btw; what
does $IMGFIX _do_, anyway?  It takes no arguments and seems to have no observ-
able effect) fix up data references as nicely as it does code references!

  Thanks in advance,

    Chris Chiesa
    [e-mail]