Authz configuration file in SVN in Linux

User group format:

[Groups]
Groupname = user1, user2, user3

One user group can contain one or more users separated by commas.

Version library directory format:
[<Version Library>:/project/directory]
@ <User group name >=< permission>
<User name >=< permission>
The box number can be written in multiple ways:
[/] Indicates the root directory and the following. The root directory is specified when svnserve is started. We specify it as/home/svn/test, [/] means to set permissions for all version libraries.
[Repos:/] indicates that you have set permissions for version Library repos;
[Repos:/abc] indicates setting permissions for the abc project in the version Library repos;
[Repos:/abc/aaa] indicates setting permissions for the aaa Directory of the abc project in the version Library repos;
The permission subject can be a user group, user, or *. The user group is preceded by @, * indicating all users.
The permission can be w, r, wr, or null. If it is null, no permission is granted.
Ex:
[/]
@ Groupname = rw

The svn + apache configuration file is nothing more than the subversion. conf configuration for the svn module of apache) authz (user role permission configuration)

Passwd (user password)
Passwd is nothing more than creating a user or changing a password.
Authz is relatively complex. The following is an example.

[Group]

Admin = aaa, bbb, ccc
Vip = a1
Man = b1
Custom = c1 // Here we first set that there are so many roles and users
// Assume that the database name is cp.
// The following two parallel directories are created under cp: vip and main.
[/]
@ Admin = rw // indicates that only admin has read and write permissions in the root directory.
[Cp:/]
* = R // in the cp database, everyone except admin has the read permission.
@ Admin = rw // in the cp Library, admin has read and write permissions
[Cp:/vip]
* = // Except vip and admin, the owner has no permissions.
@ Vip = rw //
@ Admin = rw //
[Cp:/main]
* = // Other roles except the following do not have any permissions
@ Admin = rw //
@ Vip = rw //
@ Man = r //
If there are subdirectories in some directories, roles with permissions in the directory should also have corresponding role permissions.
That is to say, sub-directories can inherit the role permissions of the parent directory.
For example, if the vip directory contains the vip1 directory, the vip and admin still have the rw permission on vip1.

3.15 supplement

@ Admin = rw // indicates that only admin has read and write permissions in the root directory.
[Cp:/]
* = R // in the cp database, everyone except admin has the read permission.
@ Admin = rw // in the cp Library, admin has read and write permissions
[Cp:/vip]
* = // Except vip and admin, the owner has no permissions.
@ Vip = rw //
@ Admin = rw //
[Cp:/main]
* = // Other roles except the following do not have any permissions
@ Admin = rw //
@ Vip = rw //
@ Man = r //
[Cp:/main/01-aaa] // admin and test can be accessed. admin can see that vip users cannot see this directory.
@ Test = rw
@ Admin = rw
Here, we will add that if the directory has special permissions, the folder will not be visible if the upper-level user has permissions but does not have specific permissions. In other words, if you have sub-directory permissions but do not have the main directory permissions, you can directly access the sub-directory through a full sub-directory link..

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

For all arm business department personnel, svn: // 192.168.0.1/diary/arm 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 last afternoon, 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.

At present, some commonly used text editing tools, MS Windows built-in "notepad", "save as" menu to save the UTF-8 format file, will automatically bring 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.