- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: ACL-reading mystery -- Big ACL v. ATR$S_READAC...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 06:55 AM
тАО01-23-2009 06:55 AM
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 08:28 AM
тАО01-23-2009 08:28 AM
Re: ACL-reading mystery -- Big ACL v. ATR$S_READACL
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 08:59 AM
тАО01-23-2009 08:59 AM
Re: ACL-reading mystery -- Big ACL v. ATR$S_READACL
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;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 10:43 AM
тАО01-23-2009 10:43 AM
Re: ACL-reading mystery -- Big ACL v. ATR$S_READACL
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 01:01 PM
тАО01-23-2009 01:01 PM
Re: ACL-reading mystery -- Big ACL v. ATR$S_READACL
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 02:06 PM
тАО01-23-2009 02:06 PM
Re: ACL-reading mystery -- Big ACL v. ATR$S_READACL
Ideally, I'd like to see the corresponding text identifiers preserved for all the IDs referenced in the saved ACLS.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 04:01 PM
тАО01-23-2009 04:01 PM
Re: ACL-reading mystery -- Big ACL v. ATR$S_READACL
> 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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-24-2009 02:38 AM
тАО01-24-2009 02:38 AM
Solutionyou 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-24-2009 10:37 PM
тАО01-24-2009 10:37 PM
Re: ACL-reading mystery -- Big ACL v. ATR$S_READACL
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-29-2009 01:28 PM
тАО01-29-2009 01:28 PM