dfs object service get extended permissions error / confusion

mirzafazlic

Hi folks,

Not sure if I am doing something wrong or is this a bug or environment issue.

We are using DFS 6.5 SP1 and using the productivity layer for C#. We have problems retrieving permissions for an object - specifically, if the ACL for the object has one accessor who has some extended permissions, then those extended permissions are returned for other accessors as well.

Here is a very simple test case:

create test user 1: nopermitsuser
- this user will have just basic READ permission specified in the ACL

create test user 2: extpermituser
- this user will have basic READ and some extended permissions specified in the acl

using dmadmin (or some other third user to avoid any possibility this is related to dm_owner) in DA/webtop create a test dm_document and on the permissions tab specify the permissions as following:

dm_world - NONE basic, NONE extended
dm_owner - DELETE basic, NONE extended
nopermituser - READ basic, NONE extended
extpermiuser - READ basic, EXTENDED_DELETE and CHANGE OWNERSHIP for extended

Now, when you try a DFS object service get call using 'nopermitsuser', it also returns the DELETE_OBJECT and CHANGE_OWNER permits.

Here is the sample code - can somebody please tell me whats happening here. Are we specifying something wrong on the permission profile? Is this even a a correct way to get the extended permissions? NOTE: when I login to webtop using the above user and check the properties, under "Your Permissions" they are displayed correctly!!!

class

Program

{

static void Main(string[] args){

string objectId = "0901e2408002fa12";

string userName = "nopermitsuser";

string userPassword = "password";

string docbase = "dev_doc_01";

Console.WriteLine("testing permissions for objectId = " + objectId + " against user" + userName);

IServiceContext context = ContextFactory.Instance.NewContext();context.AddIdentity(

new RepositoryIdentity(docbase, userName, userPassword, ""));

IObjectService objectService = ServiceFactory.Instance.GetRemoteService<IObjectService>(context, "core", http://dmdevcn1:9080/services);

PermissionProfile permissionProfile = new PermissionProfile();permissionProfile.PermissionTypeFilter =

PermissionTypeFilter.ANY;

OperationOptions operationOptions = new OperationOptions();operationOptions.PermissionProfile = permissionProfile;

ObjectIdentity o = new ObjectIdentity(new ObjectId(objectId), docbase);

ObjectIdentitySet oSet = new ObjectIdentitySet(o);

DataPackage obj = objectService.Get(oSet, operationOptions);

foreach (DataObject dataObj in obj.DataObjects){

foreach (Permission p in dataObj.Permissions){

Console.WriteLine("found permissions with name: " + p.Name + ", type = " + p.Type);}

}

Console.ReadLine();}

}

abc123

Hi,

I verified the case. I am sure now it is a bug that DFS did not get correct extend permissions for the login user. In your example, the ACL for the dm_document object is stored as:

Accessor	Permit	Permit Type
dm_word	NONE	BASIC
dm_owner	DELETE	BASIC
nopermituser	READ	BASIC
extpermiuser	READ	BASIC
extpermiuser	EXTENDED_DELETE + CHANGE_OWNERSHIP	EXTEND

DFS did not filter other accessor's extend permissions when constructing the permission for the login user.I will log a DFS bug. Thank you for finding out it!

By the way, DFS did not break the ACL. You can still get the correct permissions by other ways, i.e. ObjectService+AccessControlService.

- William