SVN server detailed permission Control

 

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. Other content such as configuration and installation is not the focus of this Article. If you have any questions, please refer to the documents listed in the "references" below.

Note that ** leading spaces are not allowed ** for any valid configuration lines in the configuration file; otherwise, errors may occur in the program, here is a prompt for ''option expected. 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 that deleting the front spaces of many rows with the same number of rows at once is a hard nut to crack, then the "column mode" editing mode of ultraedit may be of great help to you.

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. Currently, 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 the source code by yourself, 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, it may be because the monks are from Virgos and are said to have a strong perfectionist complex. Looking at svnserve. conf with a suffix, passwd and authz are not as uncomfortable as they are, but they have to be changed.

The above passwd. conf and authz. conf files can also be used as multiple code libraries. We only need to put them in the public directory, for example, in the ''d:/SVN ''directory, then the svnserve. in the conf file, use the following statement ::

Password-DB = ../passwd. conf
Authz-DB =.../../authz. conf

Or ::

Password-DB = ../passwd. conf
Authz-DB =.../../authz. conf

In this way, multiple code libraries can share the same user password and directory control configuration file, which is very convenient in some cases.

User Group of authz. conf
---------------------

The configuration segment of the ''arm/CONF/authz. conf'' file can be divided into two types: ''[ group] ''and all user group information is placed in it. The rest begin with ''[ arm:/] ''. 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 _ ''for easy 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 subversion 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!

Root directory of the project in 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. The arm is actually the name of the code base, that is, the arm created with the svnadmin CREATE Command.

-Here, '@' indicates a group name, not a user name. Because there is only one Michael in the g_manager group, you can replace the line ''@ g_manager = RW ''with ''michael = RW '', the expression has the same meaning.

-''' * ''Indicates" all others except the people mentioned above ", that is," all others except department managers ", including the strange old man, General Manager.

-''' * = R'' indicates "those users can only read but cannot write"

Project subdirectory of authz. conf
-----------------------

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
* =

The sub-directory settings have some characteristics, because we know from the requirement analysis that the sub-directory has a smaller permission range than its parent directory, and it cannot be accessed by anyone except the specified one. In this setting, pay attention to the following points:

-I bet most people who design SVN work on Unix-like platforms, so they always like to use ''/'' To identify subdirectories, while completely ignoring in MS windows is to use ''/'' to do the same thing. To represent the ''diary/Headquarters ''directory, use the format'' [arm:/diary/Headquarters. Of course, if you must use ''/'', the only result is that the subversion will ignore this part of the settings and will not be seen.

-''' * = ''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? No, because ** permissions are inherited **, sub-directories automatically have permissions for parent directories. If this row does not exist, all accounts can read files in the ''/diary/Headquarters'' directory. Although we have not set the parent directory permission for this directory, the default rule makes the permission for the ''/diary'' directory identical to that for the root directory, in this way, the remaining accounts are granted the r permission on the ''/diary/Headquarters'' directory. So simply put ,''*
The purpose of the = ''clause is to cut off permission inheritance so that the administrator can customize permissions for a directory and Its subdirectories to completely avoid the impact of permission settings on its parent directory.

-Here, you need to add the '@ g_vip = R'' sentence because 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 any of the audience members has used firewall configurations, they may feel familiar with the above configurations. However, this is different from the firewall configuration, that is, there is no ** sequential ** between configuration lines. That is to say, if I move the line ''' * = ''configured in this section to the beginning, the final effect of the configuration will not be affected.

Next let's take a look at this section ::

[Arm:/Ref]
@ G_manager = RW
@ G_docs = RW
* = R

The main point here is that the g_docs group contains a Linda account, which also appears in the g_headquarters group. This means that, linda will have read and write permissions on the two directories ''/Ref'' and ''diary/Headquarters.

Directory representation of authz. conf
-----------------------
In the previous description, we used the format ''[repos:/Some/DIR]'' to represent a directory of the project, for example, ''[arm: /diary/Headquarters] ''. In fact, subversion allows you to use the format ''' [/Some/DIR] '', that is, to represent directories without specifying the code library. In this case, the directories match all projects.

For users who use svnserve, The ''- r'' parameter is used only when svnserve is run, and multiple code libraries share the same directory permission file (authz. conf or authz. Generally, the configuration file is used independently for each code library. After all, the directory structure of each project is very different, so it is of little significance to mix it together. Therefore, for the sake of conciseness, you can leave the code library name unspecified. The code library names are all specified in this Article, mainly to expand to the same configuration file in the future to facilitate the use of Apache servers.

For Apache users, the two can be very different, because they are often used to using a public directory permission configuration file. If you use the svnparentpath command, it is very important to specify the version library name, because if you use the latter, then, the ''[/Some/DIR] ''part matches the ''[/Some/DIR]'' directory of all code library projects. If you use the svnpath command, there is no difference between the two Representation Methods. After all, there is only one version library.

Other notes for authz. conf
-----------------------

1. The ''r'' permission of the parent directory, which affects the permission of the ''w'' sub-directory

Specifically, this issue is raised because in versions 1.3.1 and earlier, there is a bug that an account must have read permission on its parent directory to have write permission on a subdirectory. So now 1.3.2 and later versions are used to facilitate the administrators who want to store multiple independent projects in a code library to assign permissions. For example, the company set up a large code library to store all employee logs, which is called diary. However, the arm business department is only one of the departments. You can do this ::

[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 Denied" will be generated immediately. Wow, it's cool.

2. Default Permissions

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

[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.

3. A small side effect of read-only permission

If ::

[Arm:/diary]
* = R

Subversion considers 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.

4. Impact of the Anon-access attribute on Directory Permissions

If you want to open your code library to everyone, you will be given the anonymous access permission. Add a line in the svnserve. conf file: ''anon-access = read ''. However, for some directories, you do not want others to see them, so for those special directories, you are in authz. configure in Conf, add authorized access persons, and add the ''* ='' flag. You think everything is okay, but if you do not find it, the special directory cannot be accessed, always prompts ''not authorized to open root of edit operation ''or ''unauthorized root opening for editing operations''
. You repeatedly check the user name and password you configured to confirm that everything is correct and the problem persists.

It turns out that subversion has a small bug. When ''anon-access = read'' and a directory is marked with ''' * = '', the above problem occurs. This bug still exists in the latest version (v1.4). It may be corrected in the next version.

The solution is to set anon-Access to none in svnserve. conf.

Improvement
====

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 ."

1. 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

2. Modify the authz. conf file of the code library and rename the corresponding directories one by one.

3. authz. conf file in UTF-8 format, and 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 ''ff Fe '', and after it is encoded by UTF-8, it is ''ef BB bf ''. Because the UTF-8 file itself does not have a bytecode problem, so there is a significant significance to the BOM for UTF-16 and Other encoding methods, for the UTF-8, there is only one role-indicating that this file is
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.

For the existing BOM UTF-8 file, for example, is Microsoft "Notepad" out, we can use ultraedit to 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. Of course, before this operation, you must ensure that the UTF-8 file saved by your ultraedit does not contain Bom.

Why does subversion hate Bom? I don't know. After all, I am just a common user, not a developer. If you are interested and have good English, please refer to this discussion: http://subversion.tigris.org/ser... ers & msgno = 51334