Uploaded image for project: 'Nuxeo Platform'
  1. Nuxeo Platform
  2. NXP-19441

Drive: remove costly and unnecessary calls to hasPermission in FileSystemItem adaptation

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 8.3-SNAPSHOT
    • Fix Version/s: 6.0-HF30, 7.10-HF08, 8.3
    • Component/s: Nuxeo Drive
    • Impact type:
      Configuration Change
    • Upgrade notes:
      Hide

      In 8.3 and later, by default, we don't perform the RemoveChildren check on the parent to compute canDelete nor the check on AddChildren to compute canCreateChild. In 7.10 and earlier the previous behaviour is kept.

      For 8.3 the previous behavior can be re-activated using:

      <extension target="org.nuxeo.runtime.ConfigurationService" point="configuration">
      <property name="org.nuxeo.drive.permissionCheckOptimized">false</property>
      </extension>

      For 7.10-HF08 (default value is "false") the new optimized behavior can be activated by using "true" above.

      For 6.0-HF30 (default value is "false") the new optimized behavior can be activated by using in nuxeo.conf:

      org.nuxeo.drive.permissionCheckOptimized=true

      Show
      In 8.3 and later, by default, we don't perform the RemoveChildren check on the parent to compute canDelete nor the check on AddChildren to compute canCreateChild. In 7.10 and earlier the previous behaviour is kept. For 8.3 the previous behavior can be re-activated using: <extension target="org.nuxeo.runtime.ConfigurationService" point="configuration"> <property name="org.nuxeo.drive.permissionCheckOptimized">false</property> </extension> For 7.10-HF08 (default value is "false") the new optimized behavior can be activated by using "true" above. For 6.0-HF30 (default value is "false") the new optimized behavior can be activated by using in nuxeo.conf: org.nuxeo.drive.permissionCheckOptimized=true
    • Sprint:
      nxfit 8.3.1

      Description

      Release Notes

      Permisison check has been optimized when adapting a document as a FileSystemItem for the Nuxeo Drive synchronization.

      Technical details

      JVM sampling during a call to GetChildren shows that DefaultFileSystemItemFactory#adaptDocument spends a lot of time in CoreSession#hasPermission.

      Attached visualvm snapshot shows that on a call with 1.000 children approximatively 2500 ms come from hasPermission.
      Yet in this cases the slowness may come partly from security since there are lots of aclr cache: ~4000 aclr per user.

      Currently there are 3 occurrences of hasPermission in AbstractDocumentBackedFileSystemItem:

          protected AbstractDocumentBackedFileSystemItem(String factoryName, FolderItem parentItem, DocumentModel doc,
                  boolean relaxSyncRootConstraint) {
              ...
              canRename = !doc.hasFacet(FacetNames.PUBLISH_SPACE) && !doc.isProxy()
                      && docSession.hasPermission(doc.getRef(), SecurityConstants.WRITE_PROPERTIES);
              DocumentRef parentRef = doc.getParentRef();
              canDelete = !doc.hasFacet(FacetNames.PUBLISH_SPACE) && !doc.isProxy()
                      && docSession.hasPermission(doc.getRef(), SecurityConstants.REMOVE)
                      && (parentRef == null || docSession.hasPermission(parentRef, SecurityConstants.REMOVE_CHILDREN));
              ...
          }
      

      We can probably remove the check on REMOVE_CHILDREN since:

      • Having REMOVE on a child and not REMOVE_CHILDREN on the parent is unlikely.
      • These flags are used by Drive to prevent making a call that would fail in case of permission not granted but if the call is done anyway it will result in a 500 error handled by Drive. And when the call is done, even if the flag was indicating a granted permission, there is no guarantee that the permission wouldn't have changed just before that.

      And one occurrence in DocumentBackedFolderItem:

          protected void initialize(DocumentModel doc) {
              this.name = docTitle;
              this.folder = true;
              this.canCreateChild = !doc.hasFacet(FacetNames.PUBLISH_SPACE)
                      && doc.getCoreSession().hasPermission(doc.getRef(), SecurityConstants.ADD_CHILDREN);
              this.canGetDescendants = true;
          }
      

      We can probably consider that being granted WRITE_PROPERTIES means being granted ADD_CHILDREN, so use canRename here.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  PagerDuty

                  Error rendering 'com.pagerduty.jira-server-plugin:PagerDuty'. Please contact your Jira administrators.