LO46238: "START TRUSTING..." TO UPDATE WORKSTATION ECL DOESN'T "STICK"

APAR status

• Closed as fixed if next.

Error description

• "Start trusting..." to update workstation ECL doesn't "stick"
  
  
  When working with Admin ECL's and testing their propagation to
  the user's local
  workstation ECL, I spotted the following anomaly which does not
  seem to be
  presented very well to the user.
  
  SUMMARY:
  
  Logged-on as an administrator, I make changes to the Admin ECL.
  When an
  end-user refreshes their workstation ECL they receive an
  Execution Security
  Alert asking if they want to trust me (the administrator) to
  update their
  workstation ECL. If they click "start trusting the signer", then
  they should
  expect to never be prompted for that operation by that user
  again. However
  Notes actually prompts them again, depending on how they
  navigate within the
  application.
  
  DETAILED STEPS TO REPRODUCE:
  
  1. Set up a Domino Domain with an admin user (i.e. the user is a
  member of the
  LocalDomainAdmins group) and another user who is not an admin.
  It is easiest to
  demonstrate this issue if you have two separate client
  workstations connected
  to your Domino Domain's admin server: one for the admin and a
  separate one for
  the non-admin.
  
  2. As the admin user, modify the default Admin ECL in some
  manner; for example,
  do the following:
  - Open the domain's names.nsf database (on the server).
  - Point to Actions > Edit Administration ECL.
  - Make some identifiable change; for example, set the "When
  signed by:" field
  to "-Default-", and check the "Access to file system" option
  under "Allow".
  - Make sure that "Allow user to modify" is checked.
  - Click "OK" to commit the change to the Admin ECL.
  
  3. (Preferably on a separate client workstation) log on to the
  Notes client as
  the non-administrative user, and view the workstation ECL: File
  > Security >
  User Security, enter your password, "What Others Do" > "Using
  Workstation".
  
  4. Refresh your workstation ECL by clicking the "Refresh All"
  button. You
  should get an Execution Security Alert (henceforth called "ESA")
  stating that a
  program signed by the administrator is attempting "Access to
  ECL" with the
  action "ECL Update".
  
  5. Select the "Start trusting the signer to execute this action"
  radio button
  and click "OK". This should return you to the User Security
  dialog and the ECL
  change that you made in step #2 should occur (for example, if
  you made the
  change suggested above under step #2, then with "When code is
  signed by" is set
  to "-Default-", the "File system" checkbox under "Allow access
  to" will now be
  checked whereas previously it was not checked). DO NOT DISMISS
  the User
  Security dialog.
  
  6. On the admin client, make another change to the Admin ECL
  (for example, with
  "When signed by" set to "-Default-", check the checkbox for
  "Access to current
  database").
  
  7. Back on the non-admin client, on the User Security dialog,
  click the
  "Refresh All" button again. You should NOT get an ESA, and the
  change made in
  step #6 should show up in your workstation ECL.
  
  8. Click OK to exit the User Security dialog, and OK again to
  acknowledge that
  that changes have been successfully made to the workstation
  ECL.
  
  9. On the admin client, make another change to the Admin ECL
  (for example, with
  "When signed by" set to "-Default-", uncheck the two checkboxes
  that you
  checked in steps #2 and #6).
  
  10. On the non-admin client, go back to the User Security dialog
  (File >
  Security > User Security, enter your password, "What Others Do"
  > "Using
  Workstation").
  
  11. Refresh the ECL by clicking the "Refresh All" button.
  
  EXPECTED RESULT: You should not get an ESA, and the update made
  in step #9
  should occur (in this example, the two previously-checked
  checkboxes should
  become un-checked).
  
  ACTUAL RESULT: You get another ESA identical to the one
  described in steps
  #4-#5. You have to click "Start trusting..." again. After doing
  that, the
  change is made to the workstation ECL as expected.
  
  It would appear that what's happening is that back in step #5
  when you clicked
  "start trusting the signer", it started trusting the admin to
  update the
  workstation ECL (as evidenced by the lack of an ESA at step #7),
  but the trust
  seems to only be temporary -- it only lasts until you dismiss
  the User Security
  dialog. When you re-invoke the User Security dialog the trust
  has gone away so
  at step #11 you're prompted again. The on-line help does not
  describe any such
  "temporary trust" -- it says that if you pick "start trusting",
  it will modify
  your workstation's ECL and begin trusting that signer to execute
  that action
  henceforth; therefore the ESA at step #11 should not have
  occurred.
  
  A person who is more experienced in this area than I am pointed
  out what might
  be going on: When I clicked "start trusting...", it allowed the
  current action
  and propagated the ECL change to the workstation, and it tried
  to add the
  signer to the workstation ECL so that they could perform the
  requested action
  in the future but since the signer isn't included on the Admin
  ECL with the
  "Access to Workstation Security ECL" privilege, that update
  probably failed --
  as evidenced by the fact that no such entry shows up on the
  "When signed by"
  listbox. Then later, there was no entry in the workstation ECL
  so it prompted
  again.
  
  However this does not justify why there is no prompt at step #7.
  If we don't
  trust the admin to perform this operation, then why can they
  perform it (with
  no prompt) at step #7?
  
  To work around this problem, I could update the Admin ECL to add
  an entry for
  my admin user, with the "Access to workstation security ECL"
  privilege. If I do
  that, it works as I was expecting: the first time, I get an ESA,
  but subsequent
  refreshes (whether I dismiss the User Security dialog in-between
  or not) I
  don't get the ESA.
  
  There seem to be two problems with this:
  
  First, when I clicked "start trusting", and I have permission to
  modify my
  workstation ECL, it should have added an entry to my workstation
  ECL with my
  administrator ID with "Modify your execution control list" (in
  other words, it
  should have behaved as I originally expected it to). The on-line
  help seems to
  confirm this.
  
  Second, if our theory about the problem is correct and it was
  not able to
  modify my workstation ECL to include an entry to grant this
  permission
  on-going, it should have told me so -- an error or warning
  dialog should have
  popped up saying that it was unable to start trusting the signer
  to perform
  that action (and hopefully offering some hint as to what to do
  about it). In
  the test case described above, this should have occurred either
  at step #7 or
  step #8.
  
  The current system behavior is counterintuitive and misleading,
  and potentially
  dangerous. It is misleading because the system appears to accept
  my request (to
  "start trusting"), but in fact it only trusts temporarily --
  only until I
  dismiss the User Security dialog. After that, it no longer
  trusts. The behavior
  is potentially dangerous because it requires the user to "Start
  trusting..."
  the same thing several times, and if users become too accustomed
  to clicking
  "Start trusting" then they are likely to do it some time when
  they should not,
  resulting in more-permissive-than-intended workstation ECL's.
  

Local fix

• xx
  

Problem summary

• The problem will be fixed in the next release of the product.
  

Problem conclusion

Temporary fix

Comments

• This APAR is associated with SPR# JJVX73RPAA.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Modules/Macros

• NA
  

Fix information

Applicable component levels

• R801 PSN

     UP