Subversion permission details

1. Background hypothesis
Xiamen central instant Company is an electronic component equipment supplier, which has an arm department responsible for the design and sales of ARM chips, and has set up an office in Beijing and Shanghai. Work logs were originally sent to the Manager by email, but this method has a disadvantage, that is, they do not have continuity. It is very troublesome to view the previous logs by email. As a result, we thought of using subversion to allow employees to edit logs on their own computers, and then transfer the logs back using SVN, which not only facilitates employees to write their own logs, but also facilitates archiving and processing of logs, when submitting logs, you only need to execute SVN update, which is much simpler than sending emails.

SVN Server Information

Server address: 192.168.0.1
Server OS: MS Windows 2000 Server Edition
CodeLocal library Directory: D: \ SVN \ arm
The directory structure of arm department documents is as follows:

Arm Department name
├ ── Diary working log directory
│ ├ ── Headquarters Headquarters working log directory
│ ├ ── Beijing office log directory
│ ─ ── SHANGHAI Shanghai office log directory
├ ── Ref public file reference directory
Temporary-Temp temporary file directory
Personnel Status

Morson, general manager of the company, doesn't have to look at anything in person, even the weekly summary of department managers. However, in order to show respect for him and satisfy his desire for power, he was given the "read all documents" permission.
Michael, department manager of arm division, prefers to get some new technologies and use SVN to manage logs. This is his idea of getting along with each other.
Scofield, a staff member from the Beijing office, and an old employee.
Lincon, Shanghai office staff, old staff, big real people
Linda, the Headquarters coordinator and secretary. The document is good and looks good.
Rory, MCU technician, Technical Support
Access permission requirement analysis

Allow the General Manager to read all files
Except for the department manager, all other personnel can only view the staff work logs of the Office.
Anonymous access not allowed
The ref directory can only be written by managers and secretaries and is read-only to others.
Everyone can write the temp directory.
2. Create a code library
Run the following command to create an arm code library under the Directory D: \ SVN on the server:

D: \ SVN> svnadmin create arm
Create the preceding directory structure in the directory F: \ temp of the client.

Run the command F: \ Temp> svnimportarmsvn: // 192.168.0.1/arm to import the structure.

[Note: nuances during import]

3. Edit the basic configuration file of the code library
Edit the arm \ conf \ svnserve. conf file of the code library as follows:

[General]
Password-DB = passwd. conf
Anon-access = none
Auth-access = write
Authz-DB = authz. conf
4. manage user accounts
Create the arm \ conf \ passwd. conf file of the code library, as follows:

[Users]
Morson = showmethemoney
Michael = mysecretpassword
Scofield = hellolittilekiller
Lincon = asyouknows111
Rory= 8809117
Linda = ilikeworldcup2006
5. Create a directory access permission Control File
Create the arm \ conf \ authz. conf file of the code library. The content is as follows:

[Groups]
G_vip = morson
G_manager = Michael
G_beijing = Scofield
G_shanghai = Lincon
G_headquarters = Rory, Linda
G_docs = Linda
[Arm:/]
@ G_manager = RW
* = R
[Arm:/diary/Headquarters]
@ G_manager = RW
@ G_headquarters = RW
@ G_vip = r
* =
[Arm:/diary/Beijing]
@ G_manager = RW
@ G_beijing = RW
@ G_vip = r
* =
[Arm:/diary/Shanghai]
@ G_manager = RW
@ G_shanghai = RW
@ G_vip = r
* =
[Arm:/Ref]
@ G_manager = RW
@ G_docs = RW
* = R
[Arm:/temp]
* = RW
6. Test
Open a DOS prompt window on the server and enter the following command:

SVN Co SVN: // 127.0.0.1/arm -- no-auth-Cache -- username Rory -- password 8809117
We should get the following directory structure:

Arm
─ ── Diary
│ ─ ── Headquarters
├ ── Ref
└ ── Temp
Modify any file in the ref directory and submit the file. The server reports an error "Access Deni"

In-depth
This chapter will detail the two configuration files involved in the previous chapter, svnserve. conf and authz. conf. By describing the configuration line by line, we will clarify some of the details.

Note that no leading space is allowed for any valid configuration line in the configuration file. OtherwiseProgramWill not be recognized. That is to say, if you directly copy the relevant configuration lines from the plain text format in this article, you need to manually delete all the four leading spaces. Of course, if you think it would be hard to delete the front spaces of many rows with the same number at once, then the "column mode" editing mode of ultraedit may be, it can help you a lot.

1 svnserve. conf
The arm \ conf \ svnserve. conf file is the configuration file of the server process svnserve.exe. We will explain it line by line as follows.

First, we will tell svnserve.exe that the user name and password are stored in the passwd. conf file. Of course, you can change it to any valid file name. For example, the default file name is passwd:

Password-DB = passwd. conf
The following two lines mean that only Authenticated Users are allowed to access the code base. Which of the following are verified users? Oh, of course, that is, those guys who hold the user name and password in the passwd. conf file. At present, only three values of read write none are allowed after the equal signs of the two rows. If you want to implement some special values, such as "Read-once", you are advised to change them by yourself.Source codeAnyway, it is also a free software:

Anon-access = none
Auth-access = write
Next is the most critical sentence. It tells svnserve.exe that the configuration of the project directory access permission is in the authz. conf file:

Authz-DB = authz. conf
Of course, when SVN 1.3.2 introduces this function, the system uses authz instead of authz. conf as the configuration file by default. However, because the monks are Virgos and have a strong perfectionist complex, watching svnserve. conf have a suffix while passwd and authz are not uncomfortable, it is hard to change.

2 authz. conf User Group
The configuration segment of the arm \ conf \ authz. conf file can be divided into two types: ''[ group] '', which contains information about all user groups. The other types starting with [arm:/] are the same. Each segment corresponds to a directory of the project, and its directory-related permissions are set in this segment.

First, we manage personnel groups so that we can change the permissions as little as possible. We have set up a total of five user groups. The group names are all prefixed with G _ to facilitate identification. Of course, the group members are separated by commas:

[Groups]
# Anyone not in this department who wants to view all documents
G_vip = morson
# Manager
G_manager = Michael
# Beijing office staff
G_beijing = Scofield
# Shanghai office staff
G_shanghai = Lincon
# General Headquarters staff
G_headquarters = Rory, Linda
# Tips: Write documents
G_docs = Linda
I did not notice that the account Linda has two groups: "headquarters" and "document officer". This is not an error because svnserve.exe allows me to set it like this. It means that this guy has more permissions than his colleague Rory, which is really convenient. What are more details? Please look down!

3. Project root directory of authz. conf
Next, we made a restriction on the project root directory, which can only be modified by the manager of the arm business department. Others can only look at it with an eye:

[arm:/]
@ g_manager = RW
* = r
[arm:/] indicates the relative root node of the directory structure, or the root directory of the arm project
here @ indicates a group name, not a user name. Of course, you can replace @ g_manager = RW with Michael = RW, Which means exactly the same.
* "all others except those mentioned above", that is, "all others except department managers ", of course, it also includes the strange old man of the General Manager
* = R, which means "those people can only read but cannot write"
4 authz. conf sub-directory of the project
then, we need to open the read and write permissions for the log directory to the headquarters staff:

[Arm:/diary/Headquarters]
@ G_manager = RW
@ G_headquarters = RW
@ G_vip = r
* =
I bet most people who design SVN work on Unix/Linux platforms, so they always like to use/to identify sub-directories, while completely ignoring in MS windows is to use \ to do the same thing. Therefore, to indicate the directory Arm \ diary \ Headquarters, we must use the format [arm:/diary/Headquarters.
* = In the last line indicates that no one except the manager, the headquarters staff, or special personnel is allowed to access this directory. Can this line be omitted?
The reason for adding @ g_vip = R is that the above explanation exists. If you do not explicitly grant the general manager the read power, he will be excluded from the general manager like others.
If anyone who has used the firewall configuration during the audience watching, they may feel familiar with the above configuration. However, this is different from the firewall configuration, that is, there is no sequence between the configuration lines. That is to say, if I move the * = line in this section to the beginning, the final effect of the entire configuration will not be affected.
Note that we did not set the permissions for the arm \ diary directory, So we directly jumped to its subdirectory to set the permissions. Of course I did this on purpose, because I want to introduce the concept of "inheritance" here.
A permission can inherit any sub-directory, and can inherit all permissions of its parent directory, unless it is explicitly set with other permissions. That is to say, the arm \ diary directory is not set after the arm directory is set, which means that the permissions of the arm directory are the same as those of the arm directory. Only the manager can read and write the permissions, and others can only stare.
[* = Can be omitted?] [overwrite with example] [inheritance of single-user permissions] [parent directory permission integration and full coverage]
Now let's take a look

Now we have mastered the power of "inheritance", which saves us a lot of time to knock on the keyboard. But now there is another problem,

If an attribute overwrites a subdirectory, the parent directory is completely overwritten.

5 other notes for authz. conf
Influence of r permission on sub-directory W permission
Specifically, this issue is raised because there is a bug in 1.3.1 and earlier versions, that is, for the write permission of sub-directories, the first directory of the project must have the read permission. Therefore, with Version 1.3.2, administrators who want to store multiple independent projects in a code library can assign permissions. For example, the company established a large code library to store all employee logs, called diary. However, the arm business department is only one of the departments. This can be done as follows:

[Diary:/]
@ G_chief_manager = RW
[Diary:/arm]
@ G_arm_manager = RW
@ G_arm = r
In this way, for all arm business department personnel, the svn: // 192.168.0.1/diary/arm url can be used as the root directory for routine operations, no matter whether it is actually a sub-directory, and when a few curious people want to try to checkout SVN: // 192.168.0.1/diary, A warning "Access Deni" will be generated immediately. Wow, it's cool.

Default Permissions
What if I do not set any permissions for a directory? Start a test immediately:

[Diary:/]
@ G_chief_manager = RW
Changed:

[Diary:/]
# @ G_chief_manager = RW
In this way, nothing is set. In my SVN Version 1.3.2, access is prohibited. That is to say, if you want someone to access a directory, you must explicitly specify this. This policy seems to be consistent with the firewall policy.

A small side effect of read-only permission
If:

[Arm:/diary]
* = R
Svnserve believes that no one is allowed to change the diary directory, including deleting, renaming, and adding.

That is to say, if you accidentally write the wrong directory name when creating a directory in the initial stage of the project, such as writing dairy due to misspelling, unless you change authz. conf. Otherwise, the svn MV command cannot be used to correct the wrong directory.

Improvement
1. Support for Chinese Directories
At work in the morning, morson came to Michael's desk and said, "Can you change our Beijing office and Shanghai office directories to Chinese, I think it's hard to look at those pinyin characters?" Michael thought, fortunately, he just learned some Unicode-related knowledge over the past two days, and then smiled and replied, "of course you can see the Chinese directory name tomorrow afternoon ."

Use the svn MV command to rename some original directories and commit them into the code base. The renamed directory structure is as follows:

Arm
Worker-work log
│ ├-Headquarters staff
│ ─-Beijing Office
│ ─-Shanghai Office
Example-company public file reference directory
Saving-temporary file storage
Modify the authz. conf file of the code library and rename the corresponding directories one by one.

Use ultraedit to convert the authz. conf file to a UTF-8 format without BOM

After the configuration file is converted to the UTF-8 format, the subversion can correctly recognize Chinese characters. Note that, however, you must ensure that the UTF-8 file does not contain the BOM. Bom is the abbreviation of byte order mark, refers to the Unicode file header is used to specify the high and low byte order of several characters, usually fffe, and after it is encoded by UTF-8, efbbbf. Since the UTF-8 file itself does not have a matter of byte order, there is a significant BOM for coding methods such as UTF-16, for the UTF-8, there is only one role-indicating that this file is in UTF-8 format. Because BOM will bring a lot of difficulties to the text processing, so now many software require the use of UTF-8 files without Bom, especially some text processing software, such as PHP, Unix script files, etc, the same is true for SVN.

Some commonly used text editing tools, MS windows built-in "Notepad", "Save as" menu to save the UTF-8 format file, will automatically carry Bom. The new version of ultraedit provides options to allow users to choose whether to require Bom, while the old version does not add Bom. Please check the instruction file of your frequently-used editor to see if it supports this function.

Using ultraedit, we can remove Bom. The method is to first use the "UTF-8 to ASCII" menu to convert the file to an encoded cost, typically gb2312 code, and then use the "ASCII to UTF-8 (UNICODE editing) to the UTF-8.