Jump to content


mcru

Member Since 30 Nov 2016
Offline Last Active May 11 2018 01:35 PM
-----

Posts I've Made

In Topic: Anyone have a way to preview p4 protect updates outside of the P4V admin tool?

03 April 2018 - 01:13 AM

View PostSambwise, on 02 April 2018 - 09:18 PM, said:

Though really, emulating the protection table (using the Spec and Map APIs) seems easier the more I think about it.  Most of the complexity is in parsing the spec and combining the mappings, and those two APIs do that work for you.

I'm actually already using the spec API, and this route seems much less intrusive vs. spinning up a temporary instance on a user machine for every ACL update.

Cool, thanks for the input guys. I'll follow up with whatever I end up actually building ;)

In Topic: Anyone have a way to preview p4 protect updates outside of the P4V admin tool?

02 April 2018 - 07:59 PM

That's actually not the worlds most terrible idea. What I'm even doing in the first place is somewhat nuts. To give you guys a little background...

I'm placing a new ACL model on top of p4 protect. We need to ACL our code down to the file level, with multiple delegated and sub-delegated paths. We also need to let the 'project' owners apply and delegate their own ACLs, without having any access to any other projects. I also need to migrate a non-trivial number of SVN repositories (which aren't even actual repositories, they are individual directories under a single repo) to p4, while maintaining the existing ACLs from SVN. The only real way to do this is to port the ACL model from our existing SVN setup over to p4.

What I'm doing is creating an acl repo that is a big tree of all p4 paths to protect, with each 'repo' owner having write access on the path to the files that will maintain the acl for their project(s). Any sub-delegated paths will write a file under this same path that is writable to the repo owner, and the users selected for sub-delegation. The sub-delegated path owners can further sub-delegate if necessary.

Each repo that is delegated to an owner or group of owners is given the owner permission in the base protects table, owned by a service user, to keep all acl lines for that path outside of the base protect table.

The new ACL model is much more simple than the p4 protects model, and much more flexible. It allows the depot or sub-delegate owners to define their own groups of users or groups of files to protect, and apply permissions in a way that are additive, but automatically get restrictive as finer grained paths are defined. These rules are written following a specified format that, when checked back into perforce, is automatically parsed/verified via pre-submit trigger. If all checks pass the file is submitted, and a post submit trigger expands the rules across all acl files related to the path to acl, plus any delegate or sub delegate files, and generates p4 protect lines. The service user that was given ownership on the path to this repo then takes the generated protect lines and updates the delegated p4 protects table file.

So far, this is working great. And it actually wasn't that bad to write with p4 python. What I need to do now is to give users a way to preview what their changes will do before they submit them. For example, a repo owner or a delegate/sub-delegate should be able to run a script against the new ACL model file they own that will combine all related files, generate the protect lines that would be applied, and then display all paths a specified user can read/write to under that path using the generated protect lines. It would be a breeze if I had access to the same algorithm that p4 uses to apply protections based on the protect table, but I can guarantee I will F this up if rolling my own check, miss some edge case, and lead someone to apply incorrect permissions. This is a huge no-no for us.

Matt - you've got me thinking now... what if I applied the protects to a local DVCS clone of the path to protect and ran the check against that? I think it would work, but I'm not a fan of writing the clone to users's disk and cleaning that up. Also, not even sure if I can apply protections to a local DVCS instance or not.

So far, I'm thinking my best bet is to test a few specific scenarios of p4 protect and force my generated protect lines to match those scenarios and those scenarios only. That way, I can write reliable tests and generate reliable previews using those tests. The only downside is this might be really limiting in what I can support protections wise.

In Topic: Anyone have a way to preview p4 protect updates outside of the P4V admin tool?

02 April 2018 - 03:35 PM

Ok, thanks, this makes sense and is probably the approach I'll have to take. I'm going to send something to support to see if they know of any existing tools or scripts I can leverage - ideally, they have something that exposes the same checks the p4 server makes on protect lines so I don't have to rely on a recreation of the rules. I'll update this thread with the response.

In Topic: Anyone have a way to preview p4 protect updates outside of the P4V admin tool?

02 April 2018 - 02:25 PM

Sure, a good example of where I biff'd the permissions was when I was trying to make the mainline stream writable to only a few people, read only to others, and make every other stream writable to everyone with permissions on that path.

I first tried something like this:

write user bob * //depot/project/*/...
write user bill * //depot/project/*/...
write user carl * //depot/project/*/...
write user joe * //depot/project/*/...
write user sally * //depot/project/*/...
read user carl * //depot/project/main/...
read user joe * //depot/project/main/...
read user sally * //depot/project/main/...

And eventually with help from support figured out taking away write and adding read isn't good enough, you need to explicitly revoke the =write permission. So, this was correct...

write user bob * //depot/project/*/...
write user bill * //depot/project/*/...
write user carl * //depot/project/*/...
write user joe * //depot/project/*/...
write user sally * //depot/project/*/...
=write user carl * -//depot/project/main/...
=write user joe * -//depot/project/main/...
=write user sally * -//depot/project/main/...

Stuff like this I understand after the explanation from support, but I'm unclear on how the protects algorithm actually does it's checks. From what I read in the admin guide, I would think my original stab at the permissions met the checks it makes.

I'm totally fine understanding the permissions levels, and probably should if I'm going to build something like this, but I was hoping there was something existing that exposed the algorithm that determines permissions based off of protect lines so I don't miss things like I did in the above.

write user carl * //depot/project/main/...
write user joe * //depot/project/main/...
write user sally * //depot/project/main/...

In Topic: p4 python - how to tell if there is a conflict that needs resolution when uns...

01 April 2018 - 09:55 PM

View PostSambwise, on 18 December 2017 - 06:02 AM, said:

If you want to figure out whether there's going to be an actual conflict for a given resolve, you need to run the merge, e.g. with "p4 merge3", and look for conflicting blocks.

I know this is old, but this was key, thanks!