ACL-reading mystery -- Big ACL v. ATR$S_READACL

[Steven Schweda]

Answers aren't pouring in on comp.os.vms, so
I'll try a different audience.

So, if I were to do a QIO with IO$_ACCESS
and ATR$C_READACL (on a disk file) to get less
than all of a big ACL, is there anything which
will tell me how many good bytes I got?

Background: A victim complaint has revealed
that "ZIP -V" doesn't do ACLs right.
("fib$l_aclctx? What's fib$l_aclctx?"
"fib$l_acl_status? What's fib$l_acl_status?")
ATR$C_ACLLENGTH gets you the real ACL size, but
ATR$S_READACL is only 512 (bytes), so a big ACL
might not fit in the "Maximum Size" buffer.
The docs say that ATR$C_READACL "Reads the
entire ACL or as much as will fit in the
supplied buffer. Only complete ACEs are
transferred." (And reality seems to agree.)
So, if the ACEs which fit are smaller than 512
bytes, there'll be some dead space at the end
of the buffer. I can scan the buffer ACE by
ACE until I hit a zero byte count (or
end-of-buffer (512 bytes)), but if there's a
clever way to get the size of the ACL data
returned, that'd be simpler, faster, and
generally more elegant. Unfortunately, if
there is such a way, I haven't spotted it.
("fib$l_acl_status" is not "fib$l_acl_iosb".)
Anyone have greater wisdom, or is the tedious
way the only way?


Some days I miss working for a company which
pays for actual support.

[Hoff]

I'm not inclined to go write my own $qio (re)producer here to see what's going on with the XQP ACL API.

In isolation, I'd tend to use sys$parse_acl and sys$format_acl and less so with the XQP ACL API. The system service API calls through to whatever widgets provide the direct API for the particular object, such as the XQP ACL API here.

Reproducer?

[Steven Schweda]

> Reproducer?

If you'd settle for _looking_ at some code,
the old stuff can be found in any Zip source
kit, [.vms]vms_pk.c. Look for "acl". My
latest is at:

ftp://antinode.info/info-zip/zip31a02/vms/vms_pk.c
http://antinode.info/ftp/info-zip/zip31a02/vms/vms_pk.c

I could probably assemble something more
free-standing if you twist my arm.

> I'd tend to use sys$parse_acl and
> sys$format_acl and less so with the XQP ACL
> API.

No one really wants to look at the data.
The idea is to package up some (low-level,
ATR$C_ADDACLENT) stuff which UnZip can use
directly to set the attributes again at the
far end. It actually works well enough (if
you do things right). The new code clears
that ACL context thing in the FIB for each
new file, which solves the big problem in the
old code.

The problem which no one is likely to hit is
the big-ACL problem, so I figured while I was
in the neighborhood, I'd try to obviate some
future whining.

The code I'd like to expunge includes this
bit, which uses the ACE byte count from the
first byte of each ACE to locate the next
ACE, and so on, until it finds the end of
the good data in the ACL buffer. If the QIO
returned the good-data byte count somewhere,
I could avoid doing this:

/* Expecting multiple reads. Advance through valid data. */
while ((ace_bytes = *acl_buf) != 0)
{
acl_bytes_read += ace_bytes;
acl_buf += ace_bytes;
}

[Steven Schweda]

Sloppy, but functional:

ftp://antinode.info/info-zip/raclx.zip
http://antinode.info/ftp/info-zip/raclx.zip

unzip -X raclx.zip ! (UnZip works right.)
cc raclx
link raclx
raclx :== $ sys$disk:[]raclx.exe
raclx

The mystery is how to get "504" out of the
first ATR$C_READACL QIO on the BIG_ACL.TXT
file (without having to scan the buffer, and
accumulate the ACE byte counts, as it does
now).

[Hein van den Heuvel]

Disclaimer... I have no hand on experience programming ACEs.

I did have a look at the COPY listings.

It seems they use RMS $DISPLAY in a loop until it returns SS$_NOMOREACE.
They provide it an XABPRO with an itemlist to decribe buffers.

There is a good bit of code involved with ACE save masks and stuff and eventually a call to $SET_SECURITY

fwiw,
Hein.

[David Jones_21]

It seems to me you have to code up the iterative readace method anyway for the case where the whole ACL won't fit in a 512 byte buffer, so just throw away the whole atr$c_readacl buffer if atr$c_acllength indicates an overflow.

Ideally, I'd like to see the corresponding text identifiers preserved for all the IDs referenced in the saved ACLS.

[Steven Schweda]

> It seems to me [...] throw away the whole
> atr$c_readacl buffer if atr$c_acllength
> indicates an overflow.

In fact, you can loop with ATR$C_READACL,
which lets you do (typically) many fewer
QIOs than if you loop with ATR$C_READACE.
The ACL context thing in the FIB climbs
faster, and all is well. It's just not so
easy as I'd like/expect, to figure out how
many good bytes are in the buffer.

Other than not clearing the context for each
file, the old Zip code just does a single
ATR$C_READACL, and hopes for the best. I was
expecting to need to use ATR$C_READACE, but a
ATR$C_READACL loop (with fewer QIOs) seemed
more attractive (except for the one
annoyance). (It even seems to work back on
VMS V5.5-2.)

[Volker Halle · Accepted solution]

Steven,

you are already using a very low-level interface within OpenVMS. If the documentation does not answer your question or curiousity, then there is only one ultimate resource: the OpenVMS source listings.

My interpretation of the source code is this:

In case of a ATR$C_READACL request, the XQP fills the user buffer by calls to EXE$ACL_READ_ACL in [SYS]SYSACLSUB. This call interface does not return the no. of bytes copied to the user buffer.

Volker.

[Steven Schweda]

> [...] This call interface does not return
> the no. of bytes copied to the user buffer.

Yeah. If you're reading one ACE, the size is
in the first byte. The guy who does the loop
(the XQP?) is the guy who should be
accumulating the sizes.

As I said, I can live with my current code
which scans the buffer. It would have been
more elegant if someone else (who had better
info) were doing it for me, though, so I
figured that is was worth an inquiry.

The ACL fix for Zip should appear in version
3.1. If anyone would like a retro-fix for
3.0, let me know.

[Steven Schweda]

.