bug #7021: CREATE permission not sufficient to save new TaxonName entity - EDIT - EDIT Project Management

Actions

Copy link

bug #7021

open

CREATE permission not sufficient to save new TaxonName entity

Added by Andreas Kohlbecker over 6 years ago. Updated 3 months ago.

Status:

Resolved

Priority:

Highest

Assignee:

Andreas Müller

Category:

cdmlib

Target version:

Release 4.11

Start date:

Due date:

% Done:

50%

Estimated time:

Severity:

critical

Found in Version:

Tags:

permission phycobank

Description

Saving a newly created name entity fails if the authenticated use is only having the TAXONNAME.[CREATE,READ] authority.

in the cdm-vaadin:eu.etaxonomy.cdm.service.CdmStore.saveBean(..) method the the bean is saved by doing a merge:

public EntityChangeEvent saveBean(T bean) {

        Type changeEventType;
        if(bean.getId() > 1){
            changeEventType = Type.MODIFIED;
        } else {
            changeEventType = Type.CREATED;
        }

        Session session = getSession();
        logger.trace(this._toString() + ".onEditorSaveEvent - session: " + session.hashCode());

        if(txNonConversational == null || (conversationHolder != null && !conversationHolder.isTransactionActive())){
            // no running transaction, start one ...
            startTransaction();
        }

        // merge the changes into the session, ...
        T mergedBean = mergedBean(bean);
        session.flush();
        commitTransction();

        return new EntityChangeEvent(mergedBean.getClass(), mergedBean.getId(), changeEventType);
}

The session.flush() after the merge causes a scheduleUpdate() which in fact is requiring the authenticated user being granted with the UPDATE authority. Below is the according stack trace:

eu.etaxonomy.cdm.database.PermissionDeniedException: [UPDATE] not permitted for 'andreas' on TaxonName[uuid:b93e9a49-5016-48d0-93ef-38c12ba3886e', toString:'TaxonName#2343<b93e9a49-5016-48d0-93ef-38c12ba3886e>']
    at eu.etaxonomy.cdm.persistence.hibernate.CdmSecurityHibernateInterceptor.checkPermissions(CdmSecurityHibernateInterceptor.java:158)
    at eu.etaxonomy.cdm.persistence.hibernate.CdmSecurityHibernateInterceptor.onFlushDirty(CdmSecurityHibernateInterceptor.java:116)
    at org.hibernate.event.internal.DefaultFlushEntityEventListener.invokeInterceptor(DefaultFlushEntityEventListener.java:348)
    at org.hibernate.event.internal.DefaultFlushEntityEventListener.handleInterception(DefaultFlushEntityEventListener.java:325)
    at org.hibernate.event.internal.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:276)
    at org.hibernate.event.internal.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
    at org.hibernate.event.internal.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:216)
    at org.hibernate.event.internal.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:85)
    at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:38)
    at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1282)
    at eu.etaxonomy.cdm.service.CdmStore.saveBean(CdmStore.java:206)

Related issues

Actions

Copy link

Updated by Andreas Kohlbecker over 6 years ago

Target version changed from Unassigned CDM tickets to Release 4.11

Actions

Copy link

Updated by Andreas Kohlbecker over 6 years ago

This problem is caused by the cache fields which are empty at the time when the merge happens. In turn of the flush these fields are being filled (in case the cache field is not protected) the CdmSecurityHibernateInterceptor detects the modification of these fields and requires the user to be granted for UPDATE:


        if (isModified(currentState, previousState, propertyNames, exculdeMap.get(baseType(cdmEntity)))) {
            // evaluate throws EvaluationFailedException
            //if(cdmEntity.getCreated())
            checkPermissions(cdmEntity, Operation.UPDATE);

The isModified method can exclude specific fields from the check. Cache fields should be excluded as long they are not set to protected via their according "protectedCache" flag.

Actions

Copy link

Updated by Andreas Kohlbecker over 6 years ago

Status changed from New to Resolved
% Done changed from 0 to 50

Applied in changeset cdmlib|7631d065e97a577e932260bf2546ab1c2b161fe2.

Actions

Copy link

Updated by Andreas Kohlbecker over 6 years ago

Assignee changed from Andreas Kohlbecker to Andreas Müller

This issue is solved now by excluding un-proteced cache fields from the modification check in the CdmHibernateSecurityInterceptor.

But there is another issue: The default value of TaxonName.protectedAuthorshipCache is true. Since this cache is protected a user with the authority TAXONNAME.[CREATE] can not create and persist a new TaxonName without setting this field to false prior doing the flush. I will create a new ticket for this issue ...

Andreas Müller please review my implementation

Actions

Copy link