Is it possible to have multiple git users logged as the same Linux user?
What I would like is that multiple admins can login as root, make a git pull to a directory assigned to them, and then git push, but so we still can see who made which changes in the git log?
Each one of your users can clone the repo for his own. That repository would have his config.user and config.email according to the person using it, and they all pull and push to the same "central" repo.
Anyway, they are all root, so there's not much to do about preventing one of this admins to commit as another one. But if they aren't evil, you can do this.
gitosis can surely help to access control the repository, too, if needed.
Personally I would say that the correct mechanism to make sure that you can track changes in this sort of case would be not to have root as a permitted username for your repository. They would all have to commit with their individual user names by logging in as themselves.
In general nobody should be logged in as root other than very briefly while performing a specific task such as installing a new package - not all of the time while developing so anything you do to make such practices unrewarding is good.
It would be safer to manage that kind of access control with an authorization layer like gitolite, instead of relying on system account.
That way, you are controlling who can pull what.
Although that wouldn't control the "where" part (where the users would pull those repos to)
Related
We are using git for source code management and own a SLES server which we use as a remote for our git repositories. We access git with SSH, using the real user names, not the single git user alternative, which would authenticate through the authorized_keys file of the git user.
A while ago, I figured out a problem with pushing to our remote. One user was able to push while another user was not able to push. So I began to analyze, why certain users are not able to push. I finally figured out what the root cause was: A bare repository on the remote always has a directory named objects, where commits are finally saved through the push process. This directory contains sub directory with the first two characters of a hash value. If a directory has not been created yet, it is created during a push to the remote.
And here's the mysterious thing about it, I cannot explain to myself: Some users create these directories with permissions rwxrwsr-x, while other users create them with rwxr-swr-x. As you can see, the set-gid bit is set, which is OK. But I cannot really explain why some users create directories with group write permissions while others do not.
The pitfall here is that if user A creates a directory without group write permissions and user B calculates a hash value that begins with the two characters of the already created directory of user A, user B cannot place files (commits) in that same directory, which makes it impossible to push to the remote for user B.
I have already watched out for default umask settings, that are probably different, but could not find different settings. All users on our SLES server have the default mask 0022, which will result in files being created with rw-r--r-- and directories with rwxr-xr-x. And this is the second mystery: Why do some users create directories in git with rwxrwsr-x (which is correct for git and intended), despite of the umask 0022?
Has anyone hints for me for further troubleshooting? What I want to achieve is that users create the objects sub directories with rwxrwsr-x.
Set
git config core.sharedRepository 0660
at the server repo. See the docs.
We are using Git for a website project where the develop branch will be the source of the test server, and the master branch will serve as the source for the live, production site. The reason being to keep the git-related steps (switching branches, pushing and pulling) to a minimum for the intended user population. It should be possible for these (not extremely technical) users to run a script that will merge develop into master, after being alerted that this would be pushed to live. master cannot be modified by normal users, only one special user can do the merge.
This is where I'm not sure how to integrate this identity change into my code below:
https://gist.github.com/jfix/9fb7d9e2510d112e83ee49af0fb9e27f
I'm using the simple-git npm library. But more generally, I'm not sure whether what I want to do is actually possible as I can't seem to find information about this anywhere.
My intention would be of course to use a Github personal token instead of a password.
Git itself doesn't do anything about user or permission management. So, the short answer is, don't try to do anything sneaky. Rather, use Github's user accounts they way they were intended.
What I suggest is to give this special user their own Github account, with their own copy of the repo. Let's say the main repo is at https://github.com/yourteam/repo, and the special repo is at https://github.com/special/repo.
The script will pull changes from the team repo's develop branch, and merge this into it's own master branch and push to https://github.com/special/repo.
Then, it will push its changes to the team's master branch. This step can optionally be a forced push, since no one else is supposed to mess with master, anyway. (In case someone does, using a forced push here means they have to fix their local repo to match the team repo later on, rather than having the script fail until someone fixes the team repo.)
At the same time, your CI software will notice that master has changed at https://github.com/special/repo, and will publish as you normally would. This is the linchpin: the CI doesn't pay attention to the team repo, so although your team has permission to change it, those changes don't make it into production.
This special user will need commit access to the team repo, in addition to its own GitHub repo. The easiest way is probably to use an SSH key, and run the git push command from the script, rather than trying to use the GitHub API.
I have an application using some template files and some developers wich are producing them.
The best way I found to mantain templates is to install git over gitolite and creates an hook to automatically checkout templates on update, in the right folders.
Well, everything on setup is up and running fine, but I have a security question.
Templates are used by a small application running with a user called runtime, with runtime group.
Gitolite uses another user/group usually git:git to manage repositories.
In the hook I must check out files into a runtime user folder and obviously it does not work.
I think about changing git group to the same of runtime, but I really don't know if there are security troubles in this solutions or there are no reasons to worry.
I'm not a security experts, but I know here is full :)
Thank's a lot, David.
It sounds to me like you don't actually want to run the checkout of the files from the hook, you just want the hook to trigger them. The checkout really wants to be run as the runtime user?
I can think of a couple of ways to do this, none of them sound amazing:
Set-up a passwordless ssh key for the git user, so it can run ssh runtime#localhost ~runtime/doUpdates.sh, and said script does the fetch and checkout.
Set-up limited sudo for the git user so it can run sudo -u runtime ~runtime/doUpdates.sh.
Set-up limited sudo for the git user so it can chown runtime:runtime -R the result of its checkout actions.
And a couple of even worse ones. :)
We are having a local repository which is accessible to a large number of people. We have to set up a Git repository there such that only certain users have checkout as well as commit privileges. How can we do that.
P.S. : This is a part of our homework assignment in which we have to develop a game and update it using a Git repository. So, if anyone feels like we should not be asking this question here, please do tell.
I'd recommend gitolite to manage user access to the repository.
Edit after comments:
gitolite is installed via git too.
I'm guessing that your teacher probably also meant to teach you – besides using git – to configure git protocols, ssh access (keys etc.).
You already got best advices: gitolite, gitosis, Pro git, adding to this man ssh, man ssh-keygen, man scp and git manual your homework should be easily solved.
Since it is homework I will try to give hints.
What files and directories do other users need to read to access (or write to commit/push into) a repository?
What methods can you use to control the permission on these files and directories?
Does your application have any configuration options that might help?
How do you set up a git repository where some users can see certain parts of the source code and other users can see all of it? I've seen lots of guides for only giving certain users commit access, but these assume everyone should have read access. I've also heard of gitosis, but I'm not sure it supports this and it hasn't had any commits in over a year so I think it's dead.
In short: you can't. Git is snapshot based (at conceptual level at least) version control system, not changeset based one. It treats project (repository) as a whole. The history is a history of a project, not a union of single-file histories (it is more than joining of per-file histories).
Using hooks like update-paranoid hook in contrib, or VREFs mechanism of gitolite, you can allow or forbid access to repository, you can allow or forbid access to individual branches. You can even forbid any commits that change things in specified subdirectory. But the project is always treated as a whole.
Well, there is one thing you can do: make a directory you want to restrict access to into submodule, and restrict access to this submodule repository.
The native git protocol doesn't support this; git assumes in many places that everybody has a complete copy of all of the history.
That said, one option may be to use git-subtree to split off part of the repository into its own subset repository, and periodically merge back.
Git doesn't support access control on the repository. You can however, implement access control on the repository yourself, by using hooks, more specifically the update hook.
Jörg has already pointed out that you can use hooks to do this. Exactly which hook(s) you need depends on your setup. If you want the permissions on a repo that gets pushed to, you'll need the update hook like he said. However, if it's on a repo that you're actually working in (committing and merging), you'll also need the pre-commit and post-merge hooks. The githooks manpage (Jörg linked to this too) notes that there's in fact a script in the contrib section demonstrating a way to do this. You can get this by grabbing a git tarball, or pull it out of git's gitweb repo: setgitperms.perl. Even if you're only using the update hook, that might be a useful model.
In general, Git is not intended for this. By now it seems to have out-of-the-box access control only up to the repository level.
But if you need just to hide some part of secret information in your Git repository (which is often the case) you can use git-crypt (https://github.com/AGWA/git-crypt) with encryption keys shared based on users GPG keys (https://gnupg.org/).
Alternatively you can use git submodules (https://git-scm.com/book/en/v2/Git-Tools-Submodules) if you can break your codebase to logical parts. Then all users receive access only to certain repositories which you then integrate into 'large' codebase through sub-modules where you add other code and allow it for only 'privileged' users.