      |
|
To authorize Git users to perform transactions with Git Fusion, you use
the p4 protect table, Git Fusion repo-specific and global
permission groups, and the default group p4 key.
For more information, see How do user permissions work?
To set up authorization:
Populate the permission groups and set the group default p4 key
(Optional) Enable pushes when Git authors lack Helix Core permissions
Run p4 protect to verify or add write
permissions for all
Helix Core
users associated with the Git users who will push changes to the Git Fusion repos.
To successfully perform a push, the Git pusher's
Helix Core
user must have write permissions to the affected files. The
Git author must also have write permissions, unless you use
the unknown_git user, the
ignore_author_permissions property, or the
change-owner property to circumvent that requirement (for
more information, see Enable pushes when Git authors lack Helix Core permissions.
As of the first 2014.1 patch, you can also configure a branch to be read-only, regardless of a user's Helix Core permissions. See Repo configuration file: key definitions and samples.
Git Fusion does not check the p4 protect table for
pull transactions, unless you enable the global p4gf_config property to require a read-access
check for all pull transactions (see Enforce Helix Core read permissions on Git pull). If you do not enable this option, you do not need to assign
permissions in the p4 protect table for users who are only
performing pulls.
Run the User and Client Initialization script (p4gf_init.py).
The global groups and the default permission p4 key are
automatically generated by the User and Client Initialization
script ( p4gf_init.py). By default,
the group owner is set as git-fusion-user. Do not
change the owner.
You can run this script any time after Git Fusion has been
initialized in your
Perforce
service with the Super User Initialization script ( p4gf_super_init.py). If p4gf_init.py has not been run, p4gf_init_repo.py will invoke it
automatically. If neither has been run, the first push or clone
against this Git Fusion server will invoke them both
automatically.
The default setting for the
git-fusion-permission-group-default p4 key is
push. Change this setting to none or
pull, using p4 key, if you want
to prevent authenticated users who are not members of a
permission group from having push access to all Git Fusion repos by default. Note that 0 (zero) has the
same effect as setting it to push.
If you set the p4 key to none, you must run p4gf_init_repo.py.
Run the Repo Initialization script ( p4gf_init_repo.py) for each repo.
p4gf_init_repo.py repo_name
This script creates the Git Fusion push and pull permission groups
for each repo you run it for. By default, the group owner is set as
git-fusion-user. Do not change the owner.
You can run this script any time after Git Fusion has been
initialized in your
Perforce
service with the Super User Initialization script ( p4gf_super_init.py). If p4gf_init.py has not been run, p4gf_init_repo.py will invoke it
automatically. If neither has been run, the first push or clone
against this Git Fusion server will invoke them both
automatically.
For more information about the p4gf_init_repo.py script and options, see
Setting up Repos.
The way you use the Helix Core permission groups and the group default p4 key depends on your needs.
By default, pull requests only check the p4 protects
table to confirm that the git-fusion-user has access to
the
Helix Core
depot location; the Git puller's read access to the
Helix Core
location is not checked unless you have enabled the global p4gf_config property to require a read-access
check for all pull transactions (see Enforce Helix Core read permissions on Git pull). Therefore, if you have not enabled this option, you must do
one of the following to prevent authenticated Git Fusion users
from pulling from a particular
Helix Core
depot location, :
Add all Git Fusion users to repo-specific pull and push permission
groups and set the git-fusion-permission-group-default
p4 key to none.
Use p4 protects to deny the
git-fusion-user (and therefore all Git Fusion users)
access to that depot location.
The following are some options:
Restrict access strictly by repo.
Enable users to push by adding them to the
git-fusion- group
for each repo they need to push to. Membership in this group also
grants pull permission. Ensure that these group members also have
repo_name-pushwrite access to the
Helix Core
depot locations associated with the repo being pushed.
Enable users to pull by adding them to each
git-fusion- group
they need to pull from.repo_name-pull
To prevent the global pull and push groups
(git-fusion-pull and git-fusion-push)
from granting access to users who are not in a repo-specific
group, keep these groups empty.
To prevent the git-fusion-permission-group-default
p4 key from giving access to users who are not in a repo-specific
group, set it to none.
Provide pull access to all repos, restricting push access.
Add users to the
git-fusion- group
for each repo they need to push to. Ensure that these group
members also have repo_name-pushwrite access to the
Helix Core
depot locations associated with the repo being pushed.
Add all users to the global git-fusion-pull group
or set the git-fusion-permission-group-default p4
key to pull.
Open push access to all Git Fusion repos for all authenticated users.
Add all users to the global git-fusion-push group or
set the git-fusion-permission-group-default p4 key to
push. If you want to enable all members to pushes to all
repos, ensure that these group members also have write
access to the
Helix Core
depot locations associated with all Git Fusion repos.
Git Fusion creates global groups git-fusion-pull and
git-fusion-push as part of its configuration script,
configure-git-fusion.sh. It creates repo groups
git-fusion- and
repo_name-pullgit-fusion- during the
first push or pull for that repo.repo_name-push
For more information about setting group permissions and p4 keys in Helix Core, see Helix Versioning Engine Administrator Guide: Fundamentals.
The Git pusher is not always the same Git user as the author and committer of the changes being pushed. While the pusher must always be a licensed Helix Core user with write permission for the depot locations being pushed to, you may not need all of your Git authors to be mapped to a licensed Helix Core user. Git Fusion provides the following tools to enable pushes when the Git author is not a Perforce user:
unknown_git user
Create this
Helix Core
user and give it
Helix Corewrite permission for the depot locations associated with
all repos for which you want to allow pushes when the Git author has
no
Helix Core
account. If your git-fusion-permission-group-default p4
key is set to pull or none, add
unknown_git to the global git-fusion-push
group or the relevant repo-specific push groups.
When a Git push request is made, Git Fusion checks to see if the Git
author has a mapped
Helix Core
account. If not, and unknown_git has write
permissions, the push goes through. If the author exists, the author
is still recorded as the submitter in the
Helix Core
changelist description. If the author does not exist, the submitter
is recorded as unknown_git.
ignore-author-permissions property
Set this configuration property to Yes in a
repo-specific configuration file to enable pushes to go through even
when the Git author does not have write (push)
permissions for the depot locations associated with the repo.
change-owner property
Set this configuration property to pusher to make the
changelist owner (submitter) the Git pusher rather than the Git
author (which is the default). Regardless of which user is set as the
changelist submitter, the full information from the Git commit is
logged in the changelist description field, including information
about the Git committer, Git author, and Git pusher. You can set this
configuration property in the global configuration file or a
repo-specific configuration file.
For more information about repo configuration files, see Setting up Repos
By default, Git Fusion checks
Helix Core
permissions only for Git push transactions, relying on user
authentication to the Git Fusion server and membership in
git-fusion-pull permission groups to control Git pull (read)
access to Git Fusion repos. However, if you want to enforce the
permissions that you have set up in the
Helix Coreprotects table on all Git pull transactions as well, you can
do so by setting the read-permission-check property in the
global p4gf_config file. See Global configuration file: keys and
default values
| |
|