Conference iosg::all-in-1_v30

    Isn't this a case of assigning the field attributes in FMS (via CM, Edit,
    Screen Image, Assign field attributes ) for the VMSUSR field (on
    SM$CREATE ?) to no Response Required ?
    
    Clive 

    Chele,
    
    I'm not 100% sure about the reason for this change, but I'm under the
    impression that it is to force a one-to-one relationship between
    ALL-IN-1 usernames and VMS usernames.
    
    This allows the use of VMS security mechanisms (ACL's and Identifiers)
    to be used for Drawer access control and security. [The ACCESS.DAT file
    holds the ACL's for access to the drawer].
    
    If you had a blank VMSUSR field, the code which adds ACL's to the
    Drawer can't determine what access to grant.
    
    I believe that you can still blank out the VMSUSR field [with some
    judicious twidling] and it will work as in V2.4. You just can't create
    drawers in such an environment. 
    
    Paul

    And I think if you have a blank VMS username (ie no owner) I believe 
    the drawer will be available to everyone on the system who cares to 
    add it.
    
    julia

    Leaving blank VMS account names is a terrible idea.  For the last few
    years ALL-IN-1 has been steadily moving away from the "feature" (first
    seen in CP/OSS) that allowed accounts to "float" between different VMS
    accounts.  That implementation was fine in the old world, but in
    today's situation where ACLs and identifiers have become critical in
    assuring system security it is a really bad, bad, bad, bad, bad, bad
    idea to continue with such outdated habits.  Of course, being a
    customer, they can do what they like, but don't let them complain when
    their security is compromised...
    
    T

    
    But than, perhaps it's the decision to use ACL's as the basis of drawer
    security that was the bad idea?
    
    I wouldn't have chosen it as a mechanism because it is totally at odds
    with the way that ALL-IN-1 worked in V2. It's also a bit slow and
    difficult to manage.
    
    Having said that, it would be just fine if ALL-IN-1 was originally
    designed with a 1:1 mapping. [Of course VMS V2 didn't have ACL's or
    Identifiers.] But to try to add this now is too late. 
    
    It's just one shortcoming of the technology used for ALL-IN-1. Whenever
    you do things like rename users or transfer them you start to find lots
    of other weak points with usernames, accounts, directories and drawers.
    
    Ah... just think what a bit of impersonation and some dynamic object
    links could do! Sigh...
    
    Paul.

Hi again,

I've just had further discussion with the customer. What he is trying to do 
is to set up a single ALL-IN-1 account for several VMS accounts. 
He has "always done it this way". 
Unfortunately it doesn't actually work any more.

What is more unfortunate is that he is following the instructions supplied in 
the ALL-IN-1 Management Guide (section 4.4.2). 

The recommendations in Item 4 are where he is coming unstuck:

4. After the shared ALL-IN-1 account is created, use the Edit (E) option to 
   edit the account and delete the VMS account name. This blank VMS account name
   allows any VMS users to log in to the shared ALL-IN-1 account.

Which is all very unattractive, and rather outdated with the advent of shared 
drawers etc, but this is the way the customer wants to do it - the way that is 
"in the book".

Chele

    So the bug is in the documentation?
    
    Whether or not we all agree with the decision to use ACLs (or not), the
    fact is that they are in use and we have to accept them.  Going back
    from this point with the benefit of 100% hindsight is not an option. So
    let's help our customers change their working habits to evolve into a
    new, more secure, world.
    
    T
    
    

    
    re .5
    
    >But than, perhaps it's the decision to use ACL's as the basis of drawer
    >security that was the bad idea?
    
    Paul,
    
    Just curious, what would you have chosen if not VMS based principles?
    Remember there was nothing like DECdas in existance when the decsions
    were being made, no fair using unfinished products.
    
    --Bob
    

    Hi Bob,
    
    There is a lot of history here, including, I gather, the fact that FCS
    was not designed with just ALL-IN-1 in mind. 
    
    This is just a hypothetical discussion - purely theoretical and my view
    only. I'm not saying that is what should happen, but simply that it
    might have proved a simpler option. [With hindsight as Tony points
    out.] I don't want to start any arguments - I'll just agree to differ.
    
    The concept of having ACL type security is fine. You must be able to
    specify who gets access to documents. We might have been able to use a
    few more access modes however and perhaps at a finer granularity (down
    to the document or folder level maybe?). VMS ACL's could - at a pinch-
    - have provided an expanded scheme of access control.
    
    If we were talking about the ALL-IN-1 world only, then I would have
    made ACCESS.DAT a drawer access control data-set which contained
    records specifying who could and could not access drawers specifying
    what levels of access were granted [possibly even a centralized access
    control data-set matching PARTITION]. This is consistent with other
    parts of ALL-IN-1 which parallel but don't actually expose the VMS
    features (e.g. PROFILE parallels SYSUAF, CABINET parallels
    disk/directory structure, an ACCESS data-set would parallel ACL's but
    for ALL-IN-1 and TL users).
    
    ALL-IN-1 obviously pre-dates ACL facilities by a long way. The problem
    in trying to use ACL's with ALL-IN-1 stems from 2 things:
    
    	- VMS associates ACL's with Identifiers which are granted to UIC's.
    	  This is only a loose mapping of identifiers and ACL's onto VMS
    	  usernames.
    
    	- ALL-IN-1 has historically loosely mapped the ALL-IN-1 user domain
    	  onto the VMS user domain
    
    I would have been happier in VMS V4 if they had chosen to map
    identifiers to VMS usernames with UIC's becoming just one more
    identifier in the process rightslist. That would have made more sense
    than enshrining UIC's forever by making them the basis of granting
    rights. Obviously VMS must have had their reasons - like file system
    and/or SYSUAF compatibility. As it is, VMS accounts can share UIC's and
    UIC's can share identifiers.
    
    The route which has been followed is to try to force a consistent
    mapping from ALL-IN-1 user to Identifier and hence ACL - and the
    reverse from Identifier to ALL-IN-1 username. This is difficult in a
    VMS context and required large chunks of extra code to be added to the
    ALL-IN-1 system. It also requires all sorts of context to be created on
    the VMS FCS system to cater for remote clients just so access control
    can be defined. [proxies, identifiers]. But we have to have a
    network and o/s interface somewhere!
    
    Customers find this scheme difficult to accept too. They complain that
    because VMS access control is used, privileges bypass ALL-IN-1 access
    control mechanisms. It may not be a rational complaint, but every
    customer criticism counts when it comes to selling products. Similarly,
    they would like the restrictions which enforce the Identifier <=>
    PROFILE mapping relaxed because now they have facilities like the ACL$
    data-set, they want to use it more widely or integrate ALL-IN-1
    security with their existing VMS security arrangements! And then there
    is the class of customer represented by this note who wanted ALL-IN-1
    to keep working the way that it used to in V2.4 - understandable if
    they have applications or operational processes built on that basis.
    
    Then there are the problems with changing the configuration. Deleting
    or transferring users. Renaming accounts. Network changes. Altering
    organisational structure. Having loosely coupled VMS and ALL-IN-1
    contexts doubles the headaches.
    
    VMS ACL's do have some benefits. They can be manipulated outside
    ALL-IN-1 which is a plus for some customers. They fit nicely with the
    VMS Auditing facilities. By using SYSUAF as a basis for access fine
    levels of access control can be achieved (e.g. Source of access, Time
    restrictions, Password security etc etc.). Of course, not all of these
    benefits extend directly to a TeamLinks environment but some do.
    
    But by building onto VMS access control, the scope of FCS is limited to
    systems which implement similar access control. By creating and
    implementing a separate access control mechanism, an ALL-IN-1 user
    domain could be defined which included users from TeamLinks, IOS, the
    O-word or wherever without creating extra context in VMS as well as in
    ALL-IN-1.
    
    In real terms, I expect the decision was much less clearcut that any of
    this. That's history and that's life. No doubt there were valid reasons
    for going in this direction. It's just that the benefits aren't as
    apparent as they might be at the present time. Perhaps eventually the
    office systems architecture will repay this effort but right now it
    is difficult to see how this scheme benefits ALL-IN-1.
    
    It might also have helped if all of ALL-IN-1 was able to adopt such a
    scheme. Look at drawer access and then compare SMU and calendar access.
    Then there are further anomalies with the OA$SHAR areas being handled
    with privileges and ACCESS.DAT being opened to get the access control
    information [what will this do to security auditing?]. 
    
    We can live with the implementation chosen but it has its limitations.
    It is certainly much better than having nothing - I just don't think
    that we should pretend that it's perfect. No scheme can be when there
    is 10+ years of history and design restrictions to cater for.
    
    Paul.

Hi again,

This certainly generated a lot more discussion than I had anticipated. 
Although I read and appreciate the responses made by everyone, I'd like to 
address the points made by Tony earlier on:

re Note 3118.7               
>    So the bug is in the documentation?
    
Unfortunately it's more than just a bug. The documentation actually recommends 
1. performing a series of actions which cannot be done - ie it is incorrect
2. performing a series of actions which contradict Digitials own 
   recommendations for security.
>    Whether or not we all agree with the decision to use ACLs (or not), the
>    fact is that they are in use and we have to accept them.  Going back

The customer WANTS the functionality described in the documentation. 
If it is possible to achieve it, I would like to be able to assist him. 
What I would NOT like to do is to tell him that it is 
1. not possible
2. not supported (I can imagine the response, "you don't support your OWN 
   documented procedures?!")

Please help me to help OUR customer.

Chele

    Chele,
    
    I think that you should be able to create an account and then blank out
    the VMSUSR field. It can be done manually using:
    
    <FORM PROFIL
    enter the key and opt to change
    use KP7 and enter GET VMSUSR = ''
    
    Alternatively, a WRITE CHANGE statement can be used.
    
    If the customer wants to correct their system so they can use the
    "documented" approach, then they will need to customize form SM$PROFILE
    and add a /OPTIONAL qualifier to the VMSUSR field. This will require
    them to also have SM$PROFILE2 through SM$PROFILE6 in the same form
    library because these 6 forms are a .FORM_SET
    
    Once they've customized the form, there should be no problem in
    blanking out the username from SM MUA E. Another form is used for
    account creation (SM$CREATE) so they wont be allowed to omit an account
    name for SM MUA C CU option.
    
    Paul.

    
    re .9
    
    Paul,
    
    >This is just a hypothetical discussion - purely theoretical and my view
    >only. I'm not saying that is what should happen, but simply that it
    >might have proved a simpler option. [With hindsight as Tony points
    >out.] I don't want to start any arguments - I'll just agree to differ.
    
    I didn't intend it to become a discussion, I was mostly curious. You 
    made alot of valid points. As the primary designer of the FCS internal
    security model, I was curious about what you thought, I also agree, 
    given hindsight I would do things differently, especially now that
    the FCS is a IOS only server, not a generic file cabinet server
    as it was meant to be (though IOS was always one of the target 
    storage managers, hence if you look at the FCS from an architectural
    perspective, there is a layer that appears to do almost nothing).
    
    As for VMS only, well there WAS a project under developement that
    basically was the FCS on Ultrix, of course it unplugged the security
    stuff and put in Ultrix stuff.  the securty code in teh FCS is a layer
    that other layers treat as a black box, ie: I want to know if this 
    user x can access object Y, yes or no.
    
    Theoretically this could be pulled and another different model put in
    (of course you have the realistic problems of routine interfaces, but
    that would be fairly minor in an FCS only world).  The problem with 
    doing this would be that IOS does not use the FCS exclusively for
    FC access (rightfully so).
    
    Oh well, like I said, I was just curious. Thanks for your opinion.
    
    --bob
    

    
    Bob,
    
    what you say does make good sense - I suspected that the history was
    something along those lines... I can see how you could pull out the
    security for VMS and plug in something equivalent for U*X. Trouble is
    that U*X hasn't had much security along the lines of ACL's. Windows NT
    is a different story of course.
    
    I think that ALL-IN-1 has a more general problem in the area of user
    domain - the existence of parallel context on VMS (UAF entry,
    directory, disk quotas, etc.) has always been a big management headache
    for system managers and SM subsystem engineers alike.
    
    Unfortunately, using ACL's extends this context further to Identifiers
    and Drawer ACL's - more things to be moved, changed, renamed or to get
    out of step with the ALL-IN-1 context. 
    
    It would be nice if VMS had done the job of getting rid of such horrors
    as trying to assign unique UICs and if extra application specific user
    context could be bound to the VMS context. This is too much to ask
    though because even the VMS context of username, disk, directory and
    identifiers are quite loosely bound. But it's the same everywhere - VMS
    even stored 3 or 4 copies of the username for process context not too long
    ago! [CTL, JIB, PCB and maybe 1 other]. We still suffer the legacy of
    RSX-11M.
    
    Perhaps some future operating system will work on the basis of
    universal object identifiers to which names can be assigned for
    mnemonic convenience. [Maybe Microsoft will do this for "Cairo"?]
    Information on access, security, quotas, etc can then be attributes of
    the user object with the possibility of adding application specific
    fields. Then when you edit a user, transfer or rename the account the
    cross-linkages will remain valid.
    
    Closest we get at the moment is DNS - which as a distributed name space
    is a good idea - but I don't think that as a piece of software it gets
    taken too seriously. Currently, it ends up being yet another piece of
    independent context! 
    
    Paul.

    I think that we have a documentation bug here.  Despite the customer's
    desire to do what's documented it must be stated that having accounts
    with blank VMS account names is bad now and the habit must be avoided.
    You can make a customization to incorporate the bad habit into the
    customer's system and this might make them happy for the short term,
    but in the long term it will only lead to disaster and they will be
    unhappy when people gain access to items they perhaps shouldn't.
    
    Tony

    
    Tony,

    It may be true to say in the context of the design choices which have
    been made that they should not be using shared ALL-IN-1 accounts but
    lets be realistic here and remember that you cannot just drop
    functionality which has worked for 10 years because it doesn't fit the
    master plan. It might be nice if we could but that is not how it works.

    It was bad enough that in V3 the completely arbitrary decision was made
    to suppress escape sequences in LIST. I wonder if the developers
    concerned realized exactly how many customers that change upset? Now we
    have another example of something similar. At least blank VMSUSR still
    works if you can set it up. 

    I think that any further attempt to expunge this functionality
    completely should get voted down right now. Instead, we should make our
    best effort to support this feature - albeit with reduced functionality
    in the drawer area.

    I'm sure none of us should need to be reminded that customers know what
    they want much better than we do and they are ultimately paying us to
    provide that. That is what customization is about. If we must change
    these areas, then equally we must retain the old functionality as an
    option. Consider it a challenge of design.
    
    Put another way... if we don't protect their investment, then they'll
    put that investment somewhere else.

    Paul.

    Hi,
    
       I agree with Paul.
    
       Many customers who have been caught by this change are unable to 
       immediately change their account creation and usage policies. They
       often have other applications etc. which rely on VMS features such
       as shared accounts.
    
       In general they tend to be well aware of any security problems and 
       accept these as part of the environment they CHOSE to use. 
       Withdrawing functionality (whether we like it or not) seems to me
       to be rather heavyhanded. We didn't even warn the customer base that
       we were considering removing it.
    
    Cheers,
    
    Iain.

    As far as I am aware we've been trying to get away from:
    
    -- Shared accounts
    -- Accounts with no VMS accounts tied to it
    
    since ALL-IN-1 V2.1 hit the streets in 1986. At least, my slides from
    several DECUS symposia going back to 1987 clearly state: "Don't use
    these type of accounts because we're going to change things in future".
    I also remember a debate about the same topic at V2.0 field test
    training in August 1984.
    
    Despite the warnings, I agree that these type of accounts persist.
    However, as we go into the PC era with TeamLinks V2 I believe that
    it's more than important that each user can be accurately verified and
    identified when they make a connection to an ALL-IN-1 IOS server.  Part
    of that identification is the association with an ALL-IN-1 account,
    after first connecting to a VMS account.  Without such verification and
    association it won't be possible for users to connect from a PC. 
    Habits have to change over time, we've been telling people for long
    enough, why do we persist in old ALL-IN-1 V1 habits?
    
    Expecting large amounts of flak.
    
    Tony

    This is not the appropriate place for a philosophical design discussion
    about VMS and ALL-IN-1 security. So please stop it :-)
    
    Although I expect that it will stop now that Paul has moved on to
    another contract.
    
    Graham

    Re. 3118.14
    >>>     I think that we have a documentation bug here. 
    ======
    Yes indeed. John Davey (current Mgt writer) has kindly checked through
    the documentation THRs, and no report can be found of this problem
    (though we have known about it for a long time). Could someone kindly
    submit an SPR, category DOC, to ensure that it gets fixed? Thanks.
          
    DaveT