Jump to content
Plastic SCM forums are now in Unity. Click here to open the new forum ×

Restricted access to directories in repository

green

Recommended Posts

green Newbie

green

Posted
Posted

Hello !

I have problems with plasticscm permissions settings.

I need to configure restricted access to certain directories in repository.

For example in repository I have directories:

dirA

dirB

dirC

I have 2 users:

user1: with access to all directrories

user2: with access only to files in dirC.

For user2 I deny all permisions for dirA and dirB.

The problem is: if user2 switched workspace to the branch with

changes made by user1 and this branch contains changes for dirA, dirB, dirC

then user2 can read changed files from dirA and dirB.

How to achieve this scenario ?

　　　　　　　　　　　　　　

I have Plastic SCM 4.1.10.284/active directory authentication.

Regards

Green

Link to comment
Share on other sites
carpediemevive Newbie

carpediemevive

Posted
Posted

I don't believe Plastic has any permissions built into beyond the repository level. In other words, I don't think you can set it so someone can view only a partial amount of the repository.

Would another setup work equally as well for you? Perhaps split these subdirectories out to separate repositories? I don't know what your particular setup is like, but if some users only know about C and don't know that A and B even exists, then couldn't C exists as a separate repository?

Link to comment
Share on other sites
green Newbie

green

Posted
  • Author
Posted

I don't believe Plastic has any permissions built into beyond the repository level. In other words, I don't think you can set it so someone can view only a partial amount of the repository.

I think you're wrong because I can set permissions for individual files, and folders (ctrl+p in GUI).

And this is this is a quote from the Security Guide (for Plastic 3):

items inherit their permissions in a file system like way (...) At any moment users can extend the permissions of a given directory to all its contained files and directories recursively, reestablishing a file system like permission inheritance model.

Would another setup work equally as well for you? Perhaps split these subdirectories out to separate repositories? I don't know what your particular setup is like, but if some users only know about C and don't know that A and B even exists, then couldn't C exists as a separate repository?

I think about it, but this is very hard to maintenance. I have many directories in tree structure - for example in simple project I have 15 dirs. For scenario one repository in one directory I need 15 repositories, selectors to mount them, permissions etc.

A lot of work .... I only need restricted access to three or four selected folders.

I also think that permissions working in "file system way" are more natural.

Link to comment
Share on other sites
green Newbie

green

Posted
  • Author
Posted

I checked the old version: 4.0.237 and permissions are working ok.

I checked again current version (4.0.284) and permissions are screwed up !!

Hello support you are here? This is a very serious security hole !

Link to comment
Share on other sites
psantosl Newbie

psantosl

Posted
Posted

Hi guys,

Ok, let me explain:

  • We're in the middle of a major refactor on the permissions structure.
  • The current permissions structure is somehow in between 3.0 and the final version of the 4.x series.
  • 3.0 allowed you to set permissions at "path level" although it ended up being cumbersome and tough to understand and use.
  • We're implementing a much simpler approach (this week it is actually being finished by a couple of developers) and yet much more powerful.

Let me share with you a working example of the upcoming path based security. Note: It is NOT YET (as of 14th June 2012) on any public release:

== deny add ==

>cm acl -user=pablo path:bin -denied=+add

>dir /B /S

bar.c

bin

moo.c

renamed.c

\bin\moo.exe

>cm ci

The selected items are about to be checked in. Please wait ...

Assembling checkin data

Validating checkin data

You don't have add permission on /bin/moo.exe.

>cm acl -user=pablo path:bin -denied=-add

Command finished succesfully

>cm ci

The selected items are about to be checked in. Please wait ...

Assembling checkin data

Validating checkin data

Uploading file data

Uploaded 6 bytes of 84 bytes (7,14%)

Uploaded 41 bytes of 84 bytes (48,81%)

Uploaded 76 bytes of 84 bytes (90,48%)

Uploaded 84 bytes of 84 bytes (100%)

Confirming checkin operation

Modified c:\Users\pablo\wkspaces\testwkspaces\wk14

Added bar.c

Added bin

Added bin\moo.exe

Added moo.c

Added renamed.c

Created changeset cs:1@br:/main@rep:default@repserver:TRISKELION:8084

== deny rm ==

>cm acl -user=pablo path:bin -denied=+rm

Command finished succesfully

>cm rm bin\moo.exe

Item bin\moo.exe has been removed.

>cm ci

The selected items are about to be checked in. Please wait ...

Assembling checkin data

Validating checkin data

You don't have rm permission on /bin/moo.exe.

== deny move ==

>cm acl -user=pablo path:bin -denied=+move

Command finished succesfully

>cm mv bin\moo.exe moo.exe

bin\moo.exe has been moved to moo.exe

>cm ci

The selected items are about to be checked in. Please wait ...

Assembling checkin data

Validating checkin data

You don't have move permission on /bin/moo.exe.

== deny ci on /doc ==

>cm acl -user=pablo path:/doc -denied=+ci

Command finished succesfully

>cm co doc\doc1.doc

The selected items are about to be checked out. Please wait ...

Item doc\doc1.doc was correctly checked out

>echo fooooooo doc\doc1.doc

fooooooo doc\doc1.doc

>cm ci

The selected items are about to be checked in. Please wait ...

Assembling checkin data

Validating checkin data

You don't have ci permission on /doc/doc1.doc.

== deny ci on /doc only on /main ==

>cm acl -user=pablo path:/doc -denied=+ci --branches=main

>cm stb main

>cm co doc\doc1.doc

>vim doc\doc1.doc

>cm ci

The selected items are about to be checked in. Please wait ...

Assembling checkin data

Validating checkin data

You don't have ci permission on /doc/doc1.doc.

>cm stb task001

>cm co doc\doc1.doc

>vim doc\doc1.doc

>cm ci

The selected items are about to be checked in. Please wait ...

Assembling checkin data

Validating checkin data

Uploading file data

Uploaded 15 bytes of 15 bytes (100%)

Confirming checkin operation

Modified doc\doc1.doc

Created changeset cs:4@br:/task001@rep:default@repserver:TRISKELION:8084

So, in 4.0 and 4.1 there's not support for path based security *right now*, but it will be ready very, very soon.

Link to comment
Share on other sites
  • 2 weeks later...
  • 1 month later...
  • 2 months later...
  • 4 months later...
green Newbie

green

Posted
  • Author
Posted

Hello again !

 

I just installed PlasticScm ( 4.1.10.404) and security system still does not work.

I read on your website http://www.plasticscm.com/infocenter/comparisons.aspx

that PlasticScm have:

- ACL-based permissions for all system objects

- Permission inheritance

 

This is not true, because permisons work only on repository level.

 

So do you have any plans to fix this within a reasonable time?

 

BTW I'm not interested in git.

Link to comment
Share on other sites
SilverKnight Newbie

SilverKnight

Posted
Posted

@green

 

I don't think manu was asking if you were interested in Git - he said "sign up for the gitSync program" to try PLASTIC SCM 4.2 - the version that has the security fixes.

I do not believe you have to do ANYTHING with Git - just "sign up" so you can download the 4.2 BETA to verify that the fix you are demanding is actually in that version and functional like you want.

 

Just pointing that out.  YOU have the OPTION to try 4.2, but only by SIGNING UP for access to it.

 

(I am in no way affiliated with codicesoftware - just a Plastic SCM User so take the above statements "with a grain of salt")

Link to comment
Share on other sites
  • 2 weeks later...
SilverKnight Newbie

SilverKnight

Posted
Posted

@codicesoftware

Are there supposed to be permissions on checking out/reading a directory?

 

Is there a MISSING permission there?  

The screen shot does NOT show a "READ" or "Check out" permission -

 

The user is denied the following:

  1. Change Permissions
  2. Change Owner
  3. Re(move?) Attribute
  4. Add (file)
  5. change (file)
  6. move (file)
  7. r(e)m(ove?) file
  8. check in (file)

 

There doesn't seem to be a permission for either check out (co) or read with the ALLOW/DENY property.

Does that permission actually exist?

 

Since there is a specific "RMATTR" permission, are the following missing too?

Does the "add" also apply to ADDING ATTRIBUTES, or should there be an ADATTR?

Does the "change" also apply to CHANGING ATTRIBUTES, or should there be an CGATTR?

 

I am assuming it is missing, since there is a specific rm that does NOT apply to attributes  (e.g. rm and rmattr are different permissions)

 

How about branch view/create/delete?

How about change set view?

What about labels view/create/delete?

Could a user do a merge (or cherry pick) to/from this directory with the available permissions?

 

 

Those all look like valid things to put restrictions on.  If they are not already on the list, could you add them for the 4.2 version before release?  Or, maybe as Green pointed out, the DOCs need to be updated to show exactly what is and is not available for restriction.

 

 

 

@green

I think it is NOT fair to say "it doesn't work" - it would be more correct to say "it isn't supported (yet)" - especially since as pointed out, there is no READ/CO permission to which you can check the DENY operation on.

Also, as psantosl pointed out in an earlier post:

 

 

So, in 4.0 and 4.1 there's not support for path based security *right now*, but it will be ready very, very soon.

Link to comment
Share on other sites
  • 2 months later...
calbzam Proficient

calbzam

Posted
Posted

Hello @green,

 

I´ve been testing the permissions system, and I haven´t found any issue. As @SilverKnight posted, there is not a READ/CO permission implemented at the path level. At the moment is not on our road map. 

 

Regarding labeling and merge permissions, they are also managed at the repository level.

 

Regards,

Carlos

Link to comment
Share on other sites
green Newbie

green

Posted
  • Author
Posted

Hello @green,

 

I´ve been testing the permissions system, and I haven´t found any issue. As @SilverKnight posted, there is not a READ/CO permission implemented at the path level. At the moment is not on our road map. 

 

Regarding labeling and merge permissions, they are also managed at the repository level.

 

Regards,

Carlos

 

 

Once again, I'll try explain the problem:

In older plastic verisons (4.0.284 and bellow) it was possible to configure restricted access to directory (see my previous posts in this topic).

In later versions of the plasticscm a permissions system for directories has been broken.

 

Someone in this thread claimed that this will be fixed soon. So I wait for it ... a year. And now you tell me:

 

there is not a READ/CO permission implemented at the path level. At the moment is not on our road map.

 

great .... But without this plasticscm is useless to me.

 

I have project with many subprojects. I have remote users (contractors) who need to have limited access to subprojects (they do not have any access to specific directories, look at my example in first post).

Without permissions on the directory level I can't configure this scenario. All subproject are in common directory, additionally, some directories are common to many projects.

So I cant see how this can be configured using separate repositories.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to topic listing
×
×
  • Create New...