In our organization perforce depot user permissions are managed through group text files. For each branch two type of files are maintained to manage the user permission under perforce version control itself. Both Write and Open permission file sample as follows.
ML_PROJECT_APPLICATION_WRITE.txt - For Write permission:-
# //DEPOT/ABCD/PROJECT/Jerd
# Permission: WRITE
dreac.leoson
ritu.bhangale
makyen
markerikson.s
bernardo.pereira
elitezen
ML_PROJECT_APPLICATION_OPEN.txt - For Open permission:-
# //DEPOT/ABCD/PROJECT/Jerd
# Permission: OPEN
areg.vera
bataklik
jeff.B
michael.chel
muthulakshmi.m
With above format we have multiple text files for each branch and now we need to remove the users permission from text file based on branch name list.
Branch name already available in our group text files. Now what is the best method remove the permission for each user? Is there any script to perform this action? since we have multiple users and branches.
I might suggest turning these text files into groups:
Group: ML_PROJECT_APPLICATION_WRITE
Users:
dreac.leoson
ritu.bhangale
makyen
markerikson.s
bernardo.pereira
elitezen
Group: ML_PROJECT_APPLICATION_OPEN
Users:
areg.vera
bataklik
jeff.B
michael.chel
muthulakshmi.m
and then specifying your protections table in terms of those groups:
Protections:
write group ML_PROJECT_APPLICATION_WRITE * //DEPOT/ABCD/PROJECT/Jerd/...
open group ML_PROJECT_APPLICATION_OPEN * //DEPOT/ABCD/PROJECT/Jerd/...
My recommendation would be to just use Perforce's interface directly rather than having your own file format and writing a script that translates it into Perforce commands, but if you do need to write that script it seems like a pretty straightforward pattern matching exercise.
Related
Is there a way to update the member revision of a big list of files via command line?
I can't use :working or :head but have to specify a different revision for each file.
As far as I know --selectionFile only takes paths as input, but not the revision numbers.
edit: I wanted to set member a very big list of files and I wanted to avoid writing the command si updaterevision ... for every file, as it takes ages to complete for that many files. Instead I wanted to know if there is a more advanced method to specify a list of files and their revisions to be able to run the updaterevision only once (like it is with :working) for the whole list of files.
But as it is said in the comment there is no such possibility.
edit2: I use MKS for a couple of years now and as I now know, there is no such possibility (at least up to MKS 11.6) to update many files to different revisions with one single command line call. But using one call per member, as was proposed, made the whole operation take up to several hours as I had many thousands of members in the sandbox and MKS needs some time to complete each sicommand.
Some time already passed since you asked for this question, here is my comment in case it could still be useful for you in the future.
First, It is not completely clear what you want to achieve. Please be more descriptive and if possible provide example.
What I understand as of now is you need to set bunch of files listed as member revision thru the command line. This is fairly simple, the most complicated is actually to have the list of files to be updated to member and the revision that you want to set as member.
I recommend you to create a batch file with the commands to make each file member. You can use Regex to do it very quick and without much trouble.
Here is an example for updating one file member revision:
si updaterevision --hostname=servername --port=portnumber --user=username --changepackageid=5873763:2 --revision=:working myfile_a1.c
where
servername = the name of the server where your sandbox is located
portnumber = the port that provides access to the server for your sandbox
username = your login user id
changepackageid = here you change the number to use your defined TASK:ChangePackage for this changes
revision = if you have a working revision that you want now to become member, just use "working" as revision, otherwise you can define specific revision number, e.g. revision=1.2
At the end you define the name of the file you want to update.
Go to you sandbox root folder, open CMD window, and run the batch file. It will execute each line applying your changes.
If you have a list of files with the revision you want as member, you can use REGEX to convert it into a batch file.
Example list of files in text file:
file1.c 1.10
file3.c 1.19
sec_file1.c 1.1.2.1
support.h 1.7
Use notepad++ or other text editor with regex support and run this search:
Once you know which regex apply, you can now use it in the notepad++ to do a simple search and replace:
Search = ([\w].[\D])\s+([\d.]+).*
Replace = si updaterevision --hostname=servername --port=portnum --user=userid --changepackageid=6123933:4 --revision=\2 \1
\1 => FileName
\2 => File revision
See image below as example:
Finally just save doc as batch file and run it.
Just speculating that if you have a large list of members along with the member revision you want to update to, then you also have an sandbox that served you to generate this list.
If so my approach would be
c:\MySandbox> si updaterevision --recurse --revision=:working
If your member/revision list come from a development path you could first have a sandbox targeting that devpath, resync, (close thesandbox if opened in gui), retarget the sandbox to the destination devpath (or mainline) you want and then issue the command above.
For an single member approach I would use 'si rlog' to generate a list of si-commands directly
si rlog -R --noheaderformat --notrailerformat --revision=:working --format="si updaterevision {membername} --revision={revision}\r\n" > updaterevs.bat.txt
Review updaterevs.bat.txt rename it to updaterevs.bat and ecxecute it.
(Be careful if using it on other sandboxes)
Other interesting readings here might be the "snapshot sandbox" feature,
checkpointing in general and variants rsp. devpaths.
Using only these features might be politically more correct in the philosophy of Integrity.
I have a few applications on Perforce and each application has a few branches. Right now only the latest branch is in actual use, the old ones are there for backtracking and debugging purposes.
Is there a way that I can disable the old branches so that no one can branch/use them?
Removing permissions to them is the best option. Since you want them to remain accessible as a historical reference, but NOT permit new changes, you'll want to remove the "write" level of permission but leave the "read" level:
write user * * -//depot/oldbranch/...
read user * * //depot/oldbranch/...
If only some groups have permissions to these branches in the first place you'd need to be careful of the placement of those lines to make sure you don't accidentally grant "read" permission to the other groups; that might mean doing something more like:
write group * * -//depot/oldbranch/...
read group dev * //depot/oldbranch/...
Or you could use the "=write" syntax instead:
=write group * * -//depot/oldbranch/...
You can also use "=branch" to prevent the old branch from being used as the source for new branches (the "=branch" permission is included with the "read" level unless you explicitly exclude it like this):
=branch group * * -//depot/oldbranch/...
For more on setting up permissions: http://www.perforce.com/perforce/r15.1/manuals/p4sag/chapter.protections.html
When I tried to simulate the permission system under Linux, some strange things came about.
I created a directory 'main' by user 'normal', and created directory 'aha' which permission is 700 using root.
so the owner of 'main' is 'normal', if the permission is 755, I can delete 'aha' just using 'normal' user although its owner is root.
but when i put a file in 'aha', everything is changed. I can not remove 'aha' due to there's still a file in it.
so, my question is, since 'aha' is 700 by root, how can 'normal' know it's empty or not?
My further question is : what does read permission of a directory really mean?
Think of a UNIX directory as a drawer of index cards in the library catalog.
In order to know what books there are, you need read permission on the "drawer". In order to create or remove new "books", you need write permissions (which give you ability to put new cards, or remove existing cards from the drawer). In order to "traverse" the directory to a lower level "sub-drawer", you need execute permission on the drawer itself.
If you already know that book /foo/bar/baz exists, you don't need read permissions on /, /foo or /foo/bar, but you do need execute permissions on all of them.
A given book could be referenced by multiple "cards" in the same or separate "drawer" (that's hard links).
A "card" can reference another card (that's symlinks). Symlinks could became "dangling" (if the other card is removed).
When a book is not referenced by any card in any of the drawers, it "evaporates" from the library.
since 'aha' is 700 by root, how can 'normal' know it's empty or not
Well, one way is to try to remove it. If you succeed, it must have been empty. If it was not empty, "normal" can't find out anymore than that, since "normal" can't read the directory, and therefore can't find how many cards are in that "drawer", or what they are called.
Update:
why do you need execute permissions to traverse a directory.
Because that's the definition of the eXecutable bit for directories. Since you can't reasonably execute a directory, that bit would be wasted otherwise. No, the . and .. files have nothing to to do with the execute bit.
very basically a file/dir permission of 700 is not seven hundred but actually
owner = 7
group = 0
everyone = 0
the numbers pertain to a permission level
0 = no permission
1 = allow to execute (run file or access directory)
2 = allow to write (manipulate)
4 = allow to read (see)
you add the permissions levels up to assign more then one permission for example
$ chmod 754 foo
gives full access to the owner (1+2+4), execute 'n' read to the group (1+4), and read to everyone (4) look at
http://www.linuxclues.com/articles/16.htm
http://www.tuxfiles.org/linuxhelp/filepermissions.html
for more info
I want to make certain folders read-only for the developers while some subfolders in that folder as write also.
For example, consider the folder structure:
Meeting/Jan/DevInfo/
Meeting/Feb/DevInfo/
Meeting/March/DevInfo/
Meeting/April/DevInfo/
Meeting/May/DevInfo/
I want the developers to have read permission to //Meeting/ but write permission to //Meeting/.../DevInfo/...
Can I use the following code?
read group developers * //Meeting/...
write group developers * //Meeting/.../DevInfo/...
I think it should be correct, but visual in P4 shows that the whole structure of //Meeting/ is write-allowed for developers.
Change the write access line to:
write group developers * //Meeting/*/DevInfo/...
The * character means "all files within the Meeting directory, excluding subdirectories".
The ... entry that you had before means "all files and subdirectories under //Meeting", so it overrode the following DevInfo/... section.
Try running the following to check what the protection levels are:
p4 protects //Meeting/...
My system administrators advice me to be careful when setting access control to files and directories. He gave me an example and I got confused, here it is:
a file with protection mode 644 (octal) contained in a directory with protection mode 730.
so it means:
File: 110 100 100 (owner, group, other: rw- r-- r--)
Directory: 111 011 000 (owner, group, other: rwx -wx ---)
How can file be compromised in this case?
It depends on what you mean by 'compromise' and it depends on who belongs to the group.
The directory permissions are critical. Since members of the group can access the directory ('x') and can modify the directory ('w'), even though they cannot list the directory (no 'r'), it means that if a member of the group knows the name of the file, that person can also remove it because removing a file requires permission to write to the directory - the file permissions are immaterial (even though commands such as 'rm' let you know when you don't have write permission on the file, that is a courtesy, because it doesn't matter to the 'unlink()' system call).
So, a member of your group (or, more precisely, a member of the group to which the directory belongs) can remove the file if they know its name. They can also read the file if they know its name, and they can create a file of the same name if the original is already missing. It appears from the file permissions that being able to read the file is not compromise - you would have denied group read access (and public read access) if that mattered.
Note that although your group members cannot modify the file, because they can delete the file and create a new one with the same name, the result is basically the same as being able to modify the file. One key difference is that you'd know which user did the mischief because that user would own the file. (Well, someone with access to that user ID did the mischief.)
Since the directory can be written to, the file could simply be overwritten with another if the attacker is in the directory owner's group.