| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 140.1 | Access to MAIN drawers is probably via file protections | AIMTEC::PORTER_T | Terry Porter, ALL-IN-1 Support, Atlanta CSC | Fri Feb 28 1992 21:07 | 18 |
| Access to a drawer (as far as the IAD option is concerned) is defined by the
access to the ACCESS.DAT file for that drawer.
The ACCESS.DAT file holds all the ACEs that are set from ALL-IN-1 to record
what access is allowed to the drawer, but the file protections of this file
will also be used to determin access if no matching ACE is found for a user.
The reason that you are seeing everyone's MAIN drawer in IAD is probably
caused by the ACCESS.DAT files having world read file protection set, or if
all the users are in the same UIC group group read. The file protections on
ACCESS.DAT should be (S:RWED,O:RWED,G,W) unless you have some pressing reason
for setting them otherwise.
I don't understand why you do not see the drawer that you deliberately gave
*WORLD access to. Could you post the output of $ DIR/SEC for the ACCESS.DAT
file for that drawer.
Terry
|
| 140.2 | The way I understand *WORLD to work | SIOG::T_REDMOND | Thoughts of an Idle Mind | Fri Feb 28 1992 22:37 | 43 |
| I think what's happening is that the IAD option creates a phantom bound
against the system partition data set (OA$DATA_SHARE:PARTITION.DAT), so
what you are seeing is just a list of pointers. Gaining access to the
actual drawer itself is quite another matter.
As Terry pointed out in -.1, each drawer has an ACCESS.DAT file that is
totally empty, but VMS can use it to place an Access Control List
containing entries for all the users that have been granted access,
together with details of their rights (execute, read, write, control).
ALL-IN-1 uses the ACCESS.DAT to check for access before it is granted,
so even if you can see the partition pointer you wouldn't be able to
see the contents of the drawer.
I think it would be fairly impossible to create a function which would
show a user which drawers they have access to, and only those drawers,
unless:
o There was the equivalent of CALACCESS.DAT, mapping drawers and
users as in Time Management
o The system was fairly small so all the drawers registered in
PARTITION could be interactively checked when a user performed IAD.
The first point is invalid as ALL-IN-1 uses the VMS security model for
drawer access (see above), this being the only possible way to permit
remote sharing in a secure manner. The second is not feasible given
the size of some ALL-IN-1 systems. Try hitting the FIND key after
selecting the SMU option to see what I mean. ALL-IN-1 is doing roughly
the same kind of processing, except that it is checking for MAIN
drawers and for MAIL_ACCESS.DAT, but you get the general idea as to the
performance that could be expected.
*WORLD is just a special identifier which indicates that everyone,
including proxy accounts accessing the drawer from elsewhere in the
network, possesses certain rights. At least, that's what I understand
it to be. No doubt Steve Freer or Stuart Maurice will correct me if I'm
wrong in what I have outlined so far.
Struggling to understand the new V3.0 functionality,
Tony
|
| 140.3 | IAD show potential access to drawers | AIMTEC::PORTER_T | Terry Porter, ALL-IN-1 Support, Atlanta CSC | Fri Feb 28 1992 23:19 | 34 |
| What IAD shows is a list of drawers to which the user has some access to
the ACCESS.DAT file for that drawer.
Access to the ACCESS.DAT file can be gained in 3 ways
- An ACL on the file, normally put there by ALL-IN-1 but can be manually
added outside ALL-IN-1.
- File Protections, normally (S:RWED,O:RWED,G,W) but may be modified outside
ALL-IN-1.
- Privs. e.g. BYPASS allows you to get at ANY drawer in the partition.
When access to ACCESS.DAT is gained via an ACL ALL-IN-1 will kindly raise it's
privs to give you access to the other files in the drawer (DOCDB.DAT, DAF.DAT,
directory files and body files). When access to ACCESS.DAT is gained by any
other means you are on your own and must also be able to get access to the other
drawer files without any help from ALL-IN-1.
IAD is therefore showing the list of drawers to which the user potentially
has access.
Prior to V3.0 setting file protections on file cab files (e.g. DOCDB.DAT)
would potentially let other users into your file cab (as it then was), the
difference with V3.0 is that a mechanism has been added to aid a user in
finding any insecure drawers (as they are now known).
I just thought of something that may have a bearing on your problem. All the
directories above a drawer directory (all they way up to the [000000] level)
must have World Execute file protection set, otherwise no-one but the drawer
owner will be able to get to the drawer, maybe this is why the drawer you
created is not showing up on IAD.
Terry
|
| 140.4 | Terry's preparing a course on FCS: must be right! | SIOG::T_REDMOND | Thoughts of an Idle Mind | Fri Feb 28 1992 23:40 | 15 |
| Two points of view (I'll bet I'm wrong - my notes on the matter are
very smudged and scrawled across some paper), one correct answer. Terry
makes good points about directory protections. Clearly users should be
advised to set proper file protections on their .DIR files else people
can/might go trawling for cabinets.
Terry, all this swotting up that you are doing for the classes at the
CSC must be resulting in some benefit...
No doubt the FC engineers will point out all the mistakes in the
answers so, and hopefully provide a definitive response.
Isn't noting wonderful late at night!
Tony
|
| 140.5 | PARTITION DSAB has smarts | IOSG::TALLETT | Mit Schuh bish hi | Sat Feb 29 1992 11:10 | 12 |
| Hi Folks!
The BIND to PARTITION isn't quite what it seems. The PARTITION
DSAB has some smarts and doesn't show you drawers you don't have
access to. I think the discussions thus far on ACCESS.DAT are
correct. I seem to remember an old bug where the ACCESS.DAT got
the wrong default protection, but that was definitely fixed.
Did an old baselevel create the ACCESS.DAT's?
Regards,
Paul_noting_on_a_Saturday!
|
| 140.6 | How to spot missing w:e's | IOSG::CARLIN | Dick Carlin IOSG, Reading, England | Sat Feb 29 1992 15:01 | 7 |
| The point that Terry mentioned at the end of .3 can easily be checked
by reading the drawer in DRM or IAD.
You will be told if the w:e is missing at any level. It's on the second
page unfortunately.
Dick
|
| 140.7 | Documentation error | IOSG::MAURICE | IOSG ain't a place to raise a kid | Mon Mar 02 1992 08:27 | 21 |
| Re .0
The IAD option allows you to bring up an index of drawers that YOU have
access to. Since you are privileged you will have access to every
drawer on the system.
> "Use the Index of Available Drawers (IAD) option and enter your user name to
> make a list of drawers that other people have given you access to."
That statement does not look right, and it's certainly open to
misinterpretation. Typing in the user name gives you a subset of
drawers, rather like when indexing a drawer you type in the folder field
to get a subset of folders.
The functionality the statement implies is not available, i.e. for a
System Manager to to bring up an index of drawers another user has
access to. Oh that it were.
Cheers
Stuart
|
| 140.8 | Still Struggling with Drawers | NEWVAX::SHEINBERG | Reda,DCO,DTN:341-2387 | Mon Mar 02 1992 20:06 | 23 |
|
Thanks for all the replies however I am still struggling with this.
How does a user see the drawers that he/she has access to?
.7: If it is not as the IAD option says how can I do this ?
I see everyones drawers top level and when I put the user names in I
only see that MAIN drawer not the one I gave them access from ALL-IN-1 MANAGER
when I gate *WORLD read access.
.1: The ACCESS.DAT is (S:RWED,O:RWED,G,W). My ALL-IN-1 system is really
very vanilla..
I have to talk to a group of USPS User's this week and convince them that the
new Shared File Cabinet is easy to use. At this point they are sold on CDMS.
And although I understand it has big security holes the customer just sees
it is easy to use. I was able to figure out CDMS after a few minutes. I
am still struggling with ALL-IN-1 V3 Sharing. So any ammunition you can
give me to tell them our shared file cabinet is easy to use will help.
|
| 140.9 | Don't use CDMS, if you want a clean cabinet | SIOG::T_REDMOND | Thoughts of an Idle Mind | Mon Mar 02 1992 20:32 | 34 |
| One point against CDMS (the Barclay Brown memorial shared File Cabinet
corruption-provoking utility) is that it does corrupt your cabinet.
That's the beginning and end of it. I cannot see how any customer would
trust something that has such a low confidence rating against a major
component from Digital. Has the customer ever spoken to anyone who has
attempted to run CDMS? There were a few people at DECUS in Anaheim who
were pretty explicit about the net effect of CDMS on their system.
That's about all I can say about it here as conferencing ethics and
Digital internal policies prevent me from being more explicit.
I think we have established that the IAD option allows a user to see
the drawers they have access to on a system. However, users don't go
near the IAD option very option. Once they have created a reference to
a drawer in their FILECAB.DAT it's there forever (at least, until they
remove the pointer again), so all they have to do is concentrate on
maintaining their FILECAB.
It wouldn't take very much customization to build tools to make the
existing system easier to use. For example, you could create a special
option that notified users of new drawers that they had been granted
access to. This option might generate a mail message to the user, with
an attribute set (maybe the FUNC attribute, maybe one of the new
attributes such as ASSOCIATED_FILE). Them, when a user read the message
they might select a function key (F20, for instance), which would read
the attribute and write details of the new drawer (extracted from
PARTITION) into the user's FILECAB.
If you can't get the *WORLD identifier to work (for some unknown
reason), try setting up some ALL-IN-1 groups and using them to define
user access. You might also take a $ DIR/FULL/SEC of an ACCESS.DAT
for a shared drawer that is causing problems and place it here so we
can see if anything immediately apparent is wrong.
Tony
|
| 140.10 | some comments | CHRLIE::HUSTON | | Mon Mar 02 1992 21:09 | 42 |
|
re all
This is an interesting note, I have a few comments.
When you talk of accessing a drawer you should keep something in mind.
With V3 there are multiple drawers per user. ALL-IN-1 acts as it always
has when it access a drawer, (raises priv etc). In alot of cases
ALL-IN-1 calls the FCS to access the drawer, the FCS acts quite
differently than ALL-IN-1. Basically (Stuart correct me if I am wrong)
the FCS will be called to do the drawer access if:
1) The drawer is remote
2) The operation is a cross-drawer operation
When the FCS is used, we use the users priv mask and rights and other
security info to call a VMS routine to check for access to ACCESS.DAT
of the specified drawer. If this says the user has access to the drawer
the FCS uses the FCS privs (sysprv mostly) to access the drawer
on behalf of the user. We don't raise privs. This is the reason for the
S:RWED protection on access.dat.
re .9
>It wouldn't take very much customization to build tools to make the
>existing system easier to use. For example, you could create a special
>option that notified users of new drawers that they had been granted
>access to. This option might generate a mail message to the user, with
>an attribute set (maybe the FUNC attribute, maybe one of the new
>attributes such as ASSOCIATED_FILE). Them, when a user read the message
>they might select a function key (F20, for instance), which would read
>the attribute and write details of the new drawer (extracted from
>PARTITION) into the user's FILECAB.
Keep in mind that the person you are granting access to may be a
remote user and the username that is used to give access may not
match his remote user name. In order to do what you suggest you would
need to be able to reverse-engineer a proxy, and this could potentially
give alot of users.
--Bob
|
| 140.11 | An example of drawer customization | SIOG::T_REDMOND | Thoughts of an Idle Mind | Mon Mar 02 1992 22:41 | 126 |
|
Re. 10
Hi Bob,
Thanks for pointing out that the script needs to be able to deal with
the needs of remote users. As a start I have coded up something (see
below) which automatically adds a drawer to FILECAB (but only if
present on the local system) from information contained in a mail
attribute.
The point I was making was that the current drawers set-up is, as
always with ALL-IN-1, only the start of something, and that user
requirements can be met with customizations. Even though the drawer
structure is new, there is no reason why it can't be used (or even
abused) as much as the rest of ALL-IN-1 has been up to now.
Tony
Use the following command to create a message with the attribute set:
MAIL PUSH
MAIL CREATE/OPEN/NOSEND
MAIL TO (list of addresses or a single user)
MAIL SUBJECT "Pointer to new shared drawer"
MAIL TEXT
MAIL TEXT "A pointer to a new shared drawer is attached to this message"
MAIL TEXT "Press F20 to add the drawer to your File Cabinet."
MAIL TEXT
MAIL TEXT "Regards, " OA$PROFIL_FULNAM
MAIL CLOSE_MESSAGE
CABINET ADD_ATTRIBUTE, "ASSOCIATED_FILE", -
"TEST_SHARED/A test of a new drawer/[REDMOND]MAIN"
MAIL SEND
CABINET REFILE_DOCUMENT, OA$WASTEBASKET
MAIL POP
Of course, you will have to change things so that the right addresses
are added, and the right drawer information is inserted.
F20 can be defined (in DEFAULT) as:
;;F20;;
DO FC_ADD_DRAWER_FROM_MAIL
Here is the script that adds a drawer record to FILECAB if the current
mail message has an attribute containing the name of a drawer.
!+
! FC_ADD_DRAWER_FROM_MAIL.SCP
!+
.LABEL START
GET OA$DISPLAY = OA$_GBL_WORKING\FORCE
GET #DRAWER_THERE = OA$N
GET #DRAWER_NAME = #DRAWER_POINTER = #DRAWER_TEMP = ""
! Check for an attribute on the current mail message
FOR FIRST CAB$ATTRIBUTES:ASSOCIATED_FILE DO -
GET #DRAWER_THERE = OA$Y\\-
GET #DRAWER_POINTER = .VALUE
.IF #DRAWER_THERE EQS OA$N THEN .GOTO NO_ATTRIBUTE
! Extract the component parts that we need from the pointer that's
! been passed in the ASSOCIATED_FILE attribute
GET #DRAWER_TEMP = #DRAWER_POINTER
GET_SYMBOL #DRAWER_TEMP, #DRAWER_NAME, "/"
GET_SYMBOL #DRAWER_TEMP, #DRAWER_PRETTY_NAME, "/"
GET_SYMBOL #DRAWER_TEMP, #DRAWER_PARTITION_KEY, "/"
GET #DRAWER_NAME = FN$UPPER(#DRAWER_NAME)
GET #DRAWER_PARTITION_KEY = FN$UPPER(#DRAWER_PARTITION_KEY)
! Check that the attribute contains a pointer to a valid drawer
GET #PARTITION_FLAG = PARTITION.UNIQUE_NAME[#DRAWER_PARTITION_KEY]
.IF #PARTITION_FLAG EQS "" THEN .GOTO NO_PARTITION_RECORD
! Check that we have at least read access to the ACCESS.DAT for the
! drawer we want to add
GET #ACCESS_FILE = PARTITION.DIRECTORY[#DRAWER_PARTITION_KEY] -
"ACCESS.DAT"
GET #PERMISSION = 0
CHECK_ACCESS OA$PROFIL_VMSUSR, #ACCESS_FILE, "R", #PERMISSION
.IF #PERMISSION EQ 0 THEN .GOTO NO_CAN_READ
! And write the details to FILECAB
WRITE ADD FILECAB NAME = #DRAWER_NAME, -
DESCRIPTION = #DRAWER_PRETTY_NAME, -
INDICATOR = "0", -
LASTDOC = "", -
UNIQUE_NAME = #DRAWER_PARTITION_KEY, -
PARTITION = "0::"
GET OA$DISPLAY = "Drawer " #DRAWER_NAME " added to your File Cabinet"
.EXIT
.LABEL NO_ATTRIBUTE
DISPLAY The message does not contain a pointer to a drawer
.EXIT
.LABEL NO_PARTITION_RECORD
DISPLAY The message contains an invalid partition pointer
.EXIT
.LABEL NO_CAN_READ
GET OA$DISPLAY = "You do not have read access to the drawer " -
#DRAWER_PARTITION_KEY
.EXIT
! V1.0 2-Mar-1992 - Tony Redmond
! Only deals with local drawers
|
| 140.12 | More info on Drawer issue | NEWVAX::SHEINBERG | Reda,DCO,DTN:341-2387 | Tue Mar 03 1992 05:08 | 253 |
| In following example I am trying to create a shared document with
*WORLD Y (REad) from the System Manager's ALLIN1 Account. THen I acces
the document from my any old TEST user account. I can access the
document but I cannot easily find it unless I know it is there. Or I
Read thru all the info on the IAD screens. THis seems to be contrary
to the responses I got in the replies .1 - .11. Thanks for your
continued patience.
=================================
HEre is the access file in [ALLIN1.MGR]
Directory DISK$OA:[ALLIN1.MGR]
ACCESS.DAT;1 File ID: (7559,5,0)
Size: 0/0 Owner: [ALLIN1]
Created: 28-FEB-1992 13:19:10.15
Revised: 28-FEB-1992 13:19:10.49 (2)
Expires: <None specified>
Backup: <No backup recorded>
File organization: Sequential
File attributes: Allocation: 0, Extend: 0, Global buffer count: 0, No version limit
Record format: Variable length
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:, World:
Access Cntrl List: None
Total of 1 file, 0/0 blocks.
Here is the output from the SCRIPT PRINT of the shared drawer and
document access:::
=================================================================
Index of Available Drawers
(Selections: 0 ) (New messages: 7 )
--------------------------------------------------------------------------------
No. Owner Drawer Description
--------------------------------------------------------------------------------
> 1 A1$SCRIPT MAIN
2 BSPANGLER MAIN
3 EHENNEGAN MAIN
4 IVP MAIN
5 KTHOMAS MAIN
6 MANAGER MAIN
7 MANAGER SHARED DOCUMENTS Documents to share with other
8 MASTIN MAIN
9 MCNEILL MAIN
10 POSTMASTER MAIN
11 SHEINBERG MAIN
12 SHEINBERG_T MAIN SHEINBERG_T - Main Drawer
13 TEST MAIN TEST - Main Drawer
--------------------------------------------------------------------------------
Move to item, and enter option (press GOLD MENU to see options, or HELP for
more information)
------------------------------------- TOP --------------------------------------
Date: 02-Mar-1992 File Cabinet Drawer Full Report Page: 1
===============================
Drawer [MANAGER]SHARED DOCUMENTS
System NEWVAX::
Owner MANAGER
Drawer name SHARED DOCUMENTS
Description Documents to share with other users
Directory DISK$OA:[ALLIN1.MGR.ZUAJHEPRR]
You have CONTROL access to the drawer
Drawer is shared with other users
Drawer is located on this system
Drawer type is ADVANCED SHARED
List of users who may access the drawer
=======================================
Shared
User or Group VMS Acct Read Create Delete Control
MANAGER Y Y Y Y Y
*WORLD Y Y
Default access for new documents
================================
Shared Delete/
User or Group VMS Acct Read Edit Refile Control
------------------------------------- TOP --------------------------------------
Date: 02-Mar-1992 File Cabinet Drawer Full Report Page: 1
===============================
Drawer [MASTIN]MAIN
System NEWVAX::
Owner MASTIN
Drawer name MAIN
Description
Directory OA$DISK:[MASTIN.OA]
You have CONTROL access to the drawer
Drawer is not shared with other users
ALL-IN-1 System Manager Mon 02-Mar-1992
File Cabinet - continued (1)
( 7 new mail messages )
Modify Document Access
--------------------------------------------------------------------------------
Title: User Changes
Drawer: SHARED DOCUMENTS Permitted Access
Delete/
User or Group Read Edit Refile Control
--------------------------------------------------------------------------------
*WORLD Y
===============================
THe following shows how it looks from a non- privileged TEST account.
The document can be read correctly from TEST. HOwever how does the user
find the document easily unless they know what the access is.
Index of Available Drawers
(Selections: 0 ) (New messages: 0 )
--------------------------------------------------------------------------------
No. Owner Drawer Description
--------------------------------------------------------------------------------
> 1 MANAGER SHARED DOCUMENTS Documents to share with other
2 MASTIN MAIN
3 MCNEILL MAIN
4 SHEINBERG MAIN
5 TEST MAIN TEST - Main Drawer
{I donot understand why I can see all these other MAIN drawers. Did not
grant read access except to SHARED DOCUMENTS}
--------------------------------------------------------------------------------
Move to item, and enter option (press GOLD MENU to see options, or HELP for
more information)
======
Index of Available Drawers
(Selections: 0 ) (New messages: 0 )
--------------------------------------------------------------------------------
No. Owner Drawer Description
--------------------------------------------------------------------------------
> 1 TEST MAIN TEST - Main Drawer
{note SHARED DOCUMENTS is not shown}
--------------------------------------------------------------------------------
Move to item, and enter option (press GOLD MENU to see options, or HELP for
more information)
================
Index of Drawers
(Selections: 0 ) (New messages: 0 )
--------------------------------------------------------------------------------
No. Drawer Description
--------------------------------------------------------------------------------
> 1 MAIN TEST - Main Drawer
{MANAGER/SHARED DOCUMENTS still not shown}
--------------------------------------------------------------------------------
Move to item, and enter option (press GOLD MENU to see options, or HELP for
more information)
==========================
CIVAGE SALES Mon 02-Mar-1992
File Cabinet
SEL Select Drawer: [MANAGER]SHARED DOCUMENTS
Folder: ALL-IN-1 V3
RFF Refile folder Title: User Changes
XFF Cross-file folder Author: ALL-IN-1 System Manager
MCF Make copy of folder Date: Modified on: 28-Feb-1992 01:18pm
DF Delete folder Number: 000001 Status:
RFD Refile document ID Index of drawers
XFD Cross-file document IF Index of folders
MCD Make copy of document I Index of documents
IA Index of attachments DRM Drawer management
FA File attachment as document SDR Select drawer
FAM File attachment as message TR Training
Enter option and press RETURN,
or press NEXT SCREEN for more options (more...)
{HOwever I can bring it in and read it. But I just cannot readily find it.
Is this the way it's suppose to work. This seems to be contrary to the
documentation as I said in 140.0 and I believe what I understand from the
discussion here.}
|
| 140.13 | exit | NEWVAX::SHEINBERG | Reda,DCO,DTN:341-2387 | Tue Mar 03 1992 06:20 | 2 |
| I tried this with directly specifying the TEST account as READ (Y) and
I got the same results as in .12 above.
|
| 140.14 | What's it all about? | IOSG::MAURICE | IOSG ain't a place to raise a kid | Tue Mar 03 1992 10:26 | 33 |
| Re .12
I'll have to confess that I really do not understand what the problem
is that you're trying to describe! Anyway here are some points that
will hopefully clear away the clouds.
1. Finding another user's drawer is analagous to finding a Notes
conference. IAD is the equivalent of DIR/CONF. If you know the name of
the user whose drawer it is, then fill that name in the usename box - it
will make the search a lot quicker.
2. You don't have to go to IAD to find a drawer. You can use SEL or SDR
and fill in the drawer information (Use GOLD E to fill in the username
and drawer name seperately). This is the equivalent of OPEN/NONOTEBOOK
in Notes.
3. In Notes it makes life a lot easier to ADD a conference to your
Notebook. So it is with Drawers, where ADR (Add drawer) will add a
given drawer to your File Cabinet. Once added you will find this drawer
on the Index of Drawers (ID), just like with Notes and an ordinary DIR.
4. The only problem I could see was that when user TEST did an IAD some
other drawers appeared. The drawers of MASTIN, MCNEILL and SHEINBERG
should not have appeared unless they had been shared. From the
manager's account use the Drawer Read option to find the drawer
directory, and then do a $dir/sec on the access.dat file in that
directory. This should tell you why.
I hope this makes it all clear.
Cheers
Stuart
|
| 140.15 | | IOSG::MAURICE | IOSG ain't a place to raise a kid | Tue Mar 03 1992 10:54 | 22 |
| Re .11
Hi Tony,
You need to watch use of the ASSOCIATED_FILE attribute. It has a
special format, and this format is used by archiving and deletion. If
you do not follow the format (as you didn't) then unexpected results
may appear. The format, from memory, dictates that the first 32
characters are a code, and then follows the filename (yes, I also think
that's awful). The filename will be archived when the document is, and
deleted when the document is. It is meant for future X400 applications,
and the code part is not yet defined, so it's best to leave blank.
Also the attribute does not pass through to remote mail systems, and so
if the message was sent to a remote user it will not give the desired
effect.
Having said all that, I like the idea.
Cheers
Stuart
|
| 140.16 | A little more info on associated_file | IOSG::BENOY | In a state of flux | Tue Mar 03 1992 11:29 | 15 |
|
RE .11, .15
Also if you mess with ASSOCIATED_FILE and put arbitrary values in there
the ARCHIVE_DOCUMENT function will not work, it will get an error since
it is trying to use part of the value of ASSOCIATED_FILE as a filename
to copy. You can then only archive a document if you delete the
relevant duff ASSOCIATED_FILE values.
The practical upshot of all this is that however attractive it may seem
to use this seemingly unused attribute for customisation it is used by
archive and by an X400 user agent. So you use it at your own peril! or
if you have a choice don't use it at all.
-Paul
|
| 140.17 | Correction to .3 | AIMTEC::PORTER_T | Terry Porter, ALL-IN-1 Support, Atlanta CSC | Tue Mar 03 1992 23:05 | 45 |
| After Bob's response in .10 I went back and re-examined by understanding around
access to drawers via file protections and found I was not quite right in
my description in .3
Now that I have reviewed how this all works it makes more sense.
There are 2 ways to access the File Cab
- FCS used for - Accessing remote drawers
- Cross drawer operations
- Reservation operations
- ALL-IN-1 used for all other access
The FCS runs with SYSPRV turned on all the time, but does not run in the user's
context and therefore can not use the user's privs or UIC to access drawer
files. The FCS relies on system file protections to gain access to drawer files.
ALL-IN-1 runs in the user's context with the user's privs and may turn on
additional privs (such as SYSPRV) under certain circumstances. This means
that ALL-IN-1 can gain access to the drawer files either via the user's
privs and UIC (ACLs or file protections) or via system file protections if
SYSPRV was turned on.
Both ALL-IN-1 and the FCS determine the ALLOWED access to a drawer or document
using the same rules, however the implementation of that access will differ
slightly due to the different contexts in which the two processes run.
The access allowed to a drawer is determined by the access VMS will allow the
user to the drawer's ACCESS.DAT file.
The access allowed to a document is determined by the access VMS will allow
the user to the document body file.
When implementing the allowed access the FCS relies on being able to access
the drawer files via system file protection.
When implementing the allowed access ALL-IN-1 will turn on SYSPRV if the user
was allowed access to the drawer because of ACLs and then will gain access to
the drawer files using the user's privs, the user's UIC (either ACLs or file
protections) or system file protections (if SYSPRV was turned on).
Hope that is all clear now.
Terry
|
| 140.18 | Using ASSOCIATED_FILE again | SIOG::T_REDMOND | Thoughts of an Idle Mind | Wed Mar 04 1992 08:17 | 4 |
| OK, if I put 50 blanks into the ASSOCIATED_FILE attribute and then load
the value I should be OK? This won't blow up archiving?
Tony
|
| 140.19 | 32 blanks | IOSG::MAURICE | IOSG ain't a place to raise a kid | Wed Mar 04 1992 08:47 | 7 |
| Re .18
I've double-checked and the magic number is 32.
Cheers
Stuart
|
| 140.20 | | SIOG::T_REDMOND | Thoughts of an Idle Mind | Wed Mar 04 1992 09:28 | 4 |
| Thanks. I'll stuff 50 blanks in there.... What are a few blank spaces
in SDAF between friends?
T
|
| 140.21 | It still won't work | IOSG::BENOY | In a state of flux | Wed Mar 04 1992 11:35 | 27 |
|
RE .18, .19, .20
I'm afraid it still won't work since the very presence of the
ASSOCIATED_FILE tag in the SDAF causes archive to do special
processing. Let me explain, when the ARCHIVE_DOCUMENT function detects
the presence of any ASSOCIATED_FILE tag it processes the value of the
tag as follows:-
If attribute tag = "ASSOCIATED_FILE"
Then
! Extract user agent code and save then copy file using everything
! after UA code.
extract 1st 32 chars from ASSOCIATED_FILE value string and save;
pass remainder of string to routine to copy file as X400 header file;
So archive will always assume that the first 32 chars are a ua code and
everything after it is a filename. If the routine that gets passed the
remainder of the string to use as a filename finds it is not valid it
will signal out and stop the document from being archived.
So which ever way you cut it you cannot use this attribute for storing
the text of your choice as it will bust archive period!
-Paul
|
| 140.22 | Update | SIOG::T_REDMOND | Thoughts of an Idle Mind | Wed Mar 04 1992 11:36 | 9 |
| If anyone is still interested, the ASSOCIATED_FILE attribute doesn't
appear to be a good candidate for the task of carrying drawer pointers
around. The MAIL SEND code won't copy the file into the shared area if
ASSOCIATED_FILE doesn't contain a pointer to a proper file (at least,
that's what it seems to me after some quick tests). So I have gone
back to the "good old" approach of using unseen characters (i.e. past
position 70) in the mail subject field.
Tony
|
| 140.23 | Why not just resolve the whole problem once and for all!! | AIMTEC::PORTER_T | Terry Porter, ALL-IN-1 Support, Atlanta CSC | Wed Mar 04 1992 15:09 | 14 |
| No matter what attributes are added to ALL-IN-1 someone somewhere will always
want another one. Why not just add a set of attributes that are for customer
use. These attributes would be stored in the SDAF, propergated in mail, but
otherwise ignored by ALL-IN-1.
No matter how clever we get at using SDAF attributes for purposes other than
they were intended, someday somewhere something will break because of it.
I guess the main problem will be transporting the attributes through mail, but
I guess X.400 (if and when it happens) will make that a lot easier.
Well that's my gripe for the day...
Terry
|
| 140.24 | We'd love to give you user-defined attributes | IOSG::SHOVE | Dave Shove -- REO-D/3C | Thu Mar 05 1992 15:31 | 6 |
| You're right, Terry - we can't transport them by (remote) mail.
This is on our list (and has been since v2.0!) to do when (/if) we
change the mail subsystem to use a more modern interface to Mailbus.
D.
|