Full Video Transcript
Hi, my name is Ryan Maffesoli, and I'm a solutions engineer here at Perforce. In this series, we're going to go over some more of the day to day functions that you'll use when administering your Helix Core server. And in today's video, specifically, we're going to talk about the protections table and how that operates.
So if you were to open up P4 Admin and take a look, if we go over to the permissions tab, you'll notice here at the bottom, we have our protections table. Up top we do have tabs to preview the protections and permissions that each user has. So we can view users and we can see what groups that are assigned in and then over here, we can actually see what they're allowed to see on a depot level. If we wanted to get a preview of that. We can also do the same thing for our groups. Or we can also view our depot tree and see who has access to certain positions if we need to kind of view or inspect any of that. But in this video, we're going to focus on the table down here and how that operates and the different types of edits we can make to change how things are being viewed by specific users or groups.
So currently I've got a very standard setup for my table. I've got the first line, which is assigning write access to all users. And so to kind of read this along column by column. The first one is our access level, which is a selection. So if we were to open this up, we can change our selections here. So right access means that I'm able to push changes back as well as pull them because each one of these permissions levels include the permissions of the one below it in these top ones here.
So write access, you can't affect the administrative functions of the server or the server configurables, but everyone who logs in, who's not a super user, will at least be able to submit back and forth to the system to the supplied directory. Next, we've got what type of permission this is and this is a user permission. And then following this, we've got a couple of wildcards placed into these next columns. So the first one is about the name of the user and by using an asterisk or a wildcard here, we're saying that any user can fulfill this field. Next, we have our host value, which is what machine does this level of permission apply to as well. And again, here, an asterisk or a wild card is denoting that this permission applies to any machine. if you were trying to limit this to possibly within your local network, if you have, if you want to assign different rules for VPN, you could come in here and also do a partial wild card.
So something on those lines would limit that IP address of who's accessing it to being within this local network here of 192.168.0. And then the final address. You can also in this host column, you can use actual host names that are qualified and DNS names and all that but it's just another way to limit it beyond just the user if you do have specific machine requirements as well. Our last two columns here, and this one is our file or folder section. This is actually a depot path of where these permissions apply. And so here, by going with this //, which denotes our base level of our server root followed by the ellipses here, or this dot dot dot which is HelixCore syntax for a recursive wildcard. So this folder, at this level, plus anything below, we've now granted access to. And, as we've mentioned, these first two slashes are our server root. Followed by anything below that, this just gives right access across the board to the entire server.
Our second line, you'll notice that I do have it one more, which is a user level permission here to assign super user status to myself because I am currently the only super user on this machine.
Now, there are a couple of things that we may want to edit, and we'll just go through and kind of run through that. So the first thing I'd like to do is that previously I've made this super users group and I prefer to assign super user status on a group level. So we can come in here and we can change this to super user group and if I were to save those edits in this super users group this test user is also part of that. So if I were to refresh now, you'll see that the test user also has that red aura there, which gives it super user status. So with super user status, you can affect server configurable as you can affect file administration, things of that nature, as well as all your standard read writes.
Some other edits you may want to make to your protections table would be to change this first line, which again, is currently allowing for write access to all depot paths and all paths on the depot. So what we can do is actually limit that. And then we can add specific lines to each individual project if we wanted to have something a little bit more locked down, where if a new user is added, they can't see absolutely everything on the server. So first thing I'm going to do is I'll come in here and add a new line. With this green arrow here next to it that we do have the delete option, and then we do have also the options to move up and down, which I'll get into a bit later.
So here I'm going to go ahead and assign right access to a group and that group name, I step over to my groups tab here, it's going to be demo_project_write so, because I have this demo project on the server, I've just set up a, group to assign right permission specifically to that.
So with that, the next one is host. I'm fine for any machine having access to this. And then I would then edit what depot path this is going to apply to. We'll go ahead and put our full depot path in here, which is //demo_project_depot/... So again, with that double slash at the front, we're saying that's our server route. Demo project depot is now a subfolder. And then with that following ellipses, we're assigning anything at that level or below to have access to. And so we can also come in here and, we can comment on these as well. So we can say "assign write permissions for demo project" which can just later on help us out to figure out where things are. And why things were added because sometimes these can get a little more complicated than our simple example here.
Now that we've got our write access given to our demo project, we can also come back up top here and we could downgrade this option to read status if we want them to be able to see it, or we can just straight up say no access. So at that point, any user that isn't part of this demo project group cannot access that depot. I mean, these other depots as well. We'll have no access to them.
The way that the permissions table and protection table works is that what's at the bottom is more important or overrides what's above it. So because the super user line is below and you typically want those super user lines or admin user lines at the bottom allows for the overwrite of this no access.
So, as it's coming through, it's saying, Hey, all users have zero access to any folder on the server. However, if you're in the super users group, you have access to all the folders on the server. So if I were to come back here and take a peek at what this user can see. We have access there. I can also, if I were to quickly come in here and let's edit this user to remove the super user status, and we go back and take a look at the permissions.
Now, this test user only has access to the demo_project_write user group, which is inheriting its permissions from here. And if we were to take a look at the permissions here, we can see that we're only seeing that demo project depot. We're not seeing the default depot that came with, and we're not seeing that other VFS demo depot that was present. So as a super user, we have everything, as a limited user we have access to what we're allowed. That can be very useful when it comes to data governance and user permissions and being able to see only what you need to work on.
So one other useful feature that you may want to use on your protections table is that you can actually use our ellipses recursive wildcard or the asterisk wildcard for that single level within this file folder declaration. So within the middle of the path somewhere. So what we can do with that has some pretty interesting effects. Now, the one caveat I will say here is that if you go to wild with this and add Those wildcards within many paths and all that, that you create a lot of work for the server to have to parse to figure out if a file is being allowed or not. So use this sparingly and only when you need it, but it is an option.
To go ahead and add our new permission, I'm going to add a line here, and I'm going to change this to read only access and for this group, which I have made over here in our groups. This only pdfs group. We're going to go ahead and do that. And from here, I'll add my //..., which means any file on the server. But then I'll also add .Pdf at the end. And this is only pdf read access. If I were to save those edits now this is in my table here, and I've given this group only access to files on the server that match this pattern. So basically anywhere on the server recursively that ends in .Pdf. And so if we jump over to P4V real quick, I'm going to open up two separate windows here. So up top, I've got my super user where you can see I've got a in that demo project main.
I've added three files of an example.py, an example.txt, and an example.Pdf. And underneath here, I'm logged in with my only pdf user. You can see in my depot view that I can only see that PDF file. So in that regard, the Python file and the text file have been excluded. And so you can use this again to limit down to specific folders, restrict access to specific extensions, and really move your access around on how everything is going to lay down in your depot.
So beyond that, one of the things I might do here is that I might move this more restrictive one up top, although really this doesn't matter between this write access because these are two separate groups, but you can see here how this no access line where no one is allowed to access anything on the server is being overridden by these lower permissions on the list. And so again, the lower on the list they are, the more important they are and then that's when they get their override.
So I hope this helps and I will see you next time.