| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
ALL-IN-1 V3.0 VMS V6.0
The problem is that there are two users A and B. A creates a shared drawer,
gives B access and then B adds the drawer to his filing cabinet. B has only been
granted READ access and sure enough he can read read the documents in the
shared drawer but cannot edit them or create new ones. So far so good, then when
he tries to read the details of the shared drawer it says the following:
List of users who may access the drawer
=======================================
Shared Delete/
User or Group VMS Acct Read Create Edit Refile Control
Error opening acl$dataset insuffient priviledge or object protection violation
Error opening acl$dataset insuffient priviledge or object protection violation
We reproduced this problem on our V6.0 system as did the customer on another
of his V6.0 systems. To reproduce the problem simply:
o Create a non privileged account
o From another account create a regular shared drawer and grant access to
the newly created account but only for READ access.
o Then enter the non priveleged account and do WP DRM ADR and add the
drawer. Then do a read of the drawer details and you should see the errors.
o You can read documents without error and the ACL's on ACCESS.DAT etc look
fine.
o If you give the non privileged account full access privs then the read is
successful.
Finally one of my colleagues wrote a script that reproduces the problem as
well. Follow the above but instead of reading the shared drawers details run the
following script and the same error will occur:
get #fc_access_file = log$oa$curdwr_direct "ACCESS.DAT"
FOR ACL$:#fc_access_file DO -
GET #fc_p_identifier = .identifier \-
GET #fc_p_shared = .shared \-
GET #fc_p_read = .read \-
GET #fc_p_write = .write \-
GET #fc_p_edit = oa$acl_reset_marker \-
GET #fc_p_delete = .delete \-
GET #fc_p_control = .control
Has anyone come across this problem,
Regards,
Richard Simpson.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3822.1 | Might be a VMS V6.0 problem | IOSG::MAURICE | I left my heart in Alcatraz | Thu Jan 27 1994 18:22 | 18 |
Hi,
This does not look good. I have reproduced the problem and what you
report is correct. It looks like VMS V6.0 is the culprit.
Unfortunately I haven't got a copy of the VMS V6.0 release notes, but
it looks like the underlying problem is that ACL$ uses the $change_acl
system service which has been obsoleted on the VAX (but not AXP) by
$GET_SECURITY. Though $change_acl is still there it looks like it works
differently now.
One hopeful sign is that $dir/sec works OK.
Will let you know more if I find out any more.
Cheers
Stuart
| |||||