danielupton Posted October 24, 2011 Report Share Posted October 24, 2011 Hi everyone.. Our team is running on the Plastic 4.0 beta. We're currently about 10 strong with about 5 repositories.. As the "source administrator guy" i'd like to lock plastic down to the point where any new users created automatically have access to nothing, and then receive access when assigned to groups etc. At the moment it's the other way round. I have read the security guide (found here: http://www.plasticscm.com/releases/3.0.1/manuals-html/en/securityguide.htm ) about 2 or 3 times and am still not entirely clear on how to achieve this.. Here are the steps i have taken (from the gui): Created "Test User" Went to manage his permissions for the server. Unchecked all access checkboxes (attempting to disable all access). Hit "Apply" and the user disappears from the "Users and groups" section. Am i doing this completely wrong? Thanks Link to comment Share on other sites More sharing options...
manu Posted October 24, 2011 Report Share Posted October 24, 2011 Hi Daniel! First of all set a valid administrator (the one who has full control) as the owner of the repository server object, just in case. if you uncheck all the checkboxes is the same as if you don´t add the user. So try to deny the permissions instead of uncheck the granted permissions. Use the repository server permissions instead of the repository permissions due to all objects inherit permissions from the repository server acl. Regards, manu Link to comment Share on other sites More sharing options...
danielupton Posted October 24, 2011 Author Report Share Posted October 24, 2011 Hi manu! Thanks.. the only problem with that is that users need to be able to access some repos but not others, So won't denying at a server level be inherited in all repositories? Thanks Link to comment Share on other sites More sharing options...
manu Posted October 24, 2011 Report Share Posted October 24, 2011 Hi Daniel, The repository acl inherits, by default, from the Repository Server ACL. You can customize your security by cutting the inheritance and setting it as your needs. Regards, manu Link to comment Share on other sites More sharing options...
danielupton Posted October 26, 2011 Author Report Share Posted October 26, 2011 Forgive me if i'm being really stupid.. but by cutting the inheritance, Won't that defeat the whole point by getting rid of the "blanket" of security set on the repo server? Perhaps i'm not explaining myself properly.. Heres an example: Organation FooBar has a team of 10 devs split into smaller teams of 2. When a developer joins the org they should have access to none of the repositories until granted by the team lead. So the permissions on the server are set to deny access (which is inherited in every repository). To allow them access to a repository the team lead "breaks" the inheritance on the repository and assigns them proper access and the world is right again.. What happens when another developer joins the organisation, and they are denied access at a server level? Surely because the inheritance has been broken on the repository they will have access to that repository regardless of their server access (because the repository doesn't inherit the permissions)? Obviously i can directly deny them access on the repository, but that gets really cumbersome.. and what happens when we're an organisation of 1,000 with hundreds of repositories? Thanks Daniel Link to comment Share on other sites More sharing options...
manu Posted October 26, 2011 Report Share Posted October 26, 2011 Hi Daniel! What I would do is create a group for each pair of developers. Set the repository server owner to a super root. Add the devs groups to the repository server permissions and set the permissions as you want, I recommend to you to be generous here and in lower object level restrict the access denying permissions, leaving the "cut inheritance" as the last option due to breaks with all the security flow. Remove the ALL_USERS special group from the repository server permissions and work using the groups. We are now reviewing the security for Plastic 4.0 so if you have any suggestion or any feedback from the permissions GUI usage is the time to say it! Regards. manu Link to comment Share on other sites More sharing options...
danielupton Posted October 26, 2011 Author Report Share Posted October 26, 2011 Okay thanks.... Still seems a little of a pain cause you'd have to go through all repo's their not allowed to see and deny access to each team.. We are now reviewing the security for Plastic 4.0 so if you have any suggestion or any feedback from the permissions GUI usage is the time to say it! The age old UX request.. Make it simple enough for my grandma to use! And I think this kind of configuration would be a big request in paranoid corperates so i'd recommend reviewing a "dead simple" way of doing this. Thanks so much for your help - Daniel Link to comment Share on other sites More sharing options...
manu Posted October 27, 2011 Report Share Posted October 27, 2011 Hi Daniel, one question, each dev team has access to their own repository and nothing more? Regards, manu Link to comment Share on other sites More sharing options...
danielupton Posted October 31, 2011 Author Report Share Posted October 31, 2011 Hey, yeah... apart from an "administrators" group Link to comment Share on other sites More sharing options...
danielupton Posted October 31, 2011 Author Report Share Posted October 31, 2011 Oh but some users may belong to multiple groups (as they switch between projects). So Dave is in "Project Foo Team", but is starting to also become part of the "Project Bar Team" Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.