On Mon, Jul 24, 2023 at 12:58:49AM -0700, aksrin...@gmail.com wrote: > I am new to the implementation of git and i had a requirement where i need > to control user access to specific git repositories. > > For ex: I have 3 different projects for which i create 3 different git > repositories and grant access permissions to specific users based on the > projects they are working. I have tried the following way but all the users > created on Linux server are able to access all the repositories created > under each user. It is not getting restricted to specific Linux User. > > > 1. Create three Linux users, one for each repository: Proejct1, > Project2, and Project 3 > 2. Login into each user and create the bare Git repository > 3. For each user, create ~/.ssh/authorized_keys > (/home/Project1/.ssh/authorized_keys) and add the public SSH key for each > user that should have access > > I am not sure what needs to be done to provide access to the user for the > git repository created under his user and do not allow other users to > access the Git repository created under another user > > Please suggest me the list of steps that needs to be implement to control > access to specific Git repositories or any git commands that needs to be > executed for this implementation?
Well, the first thing to note is that Git itself provides quite "bare-bones" implementation of access controls to its repositories and when fine-grained control is required, this is usually deferred to third-party software - either "turn-key" solutions such as GitLab (or its fully free altervatives like Gitea) or lower-profile but nonetheless quite powerful tools like Gitolite [1]. While you did not explicitly state your end goals, I can conjure you would like to have the following: - A single server running an OS based on Linux. - Multiple users have SSH access to that server, each using their own account. - Each user has one or more Git repositories (located under their own respective home directories), and... - Each user is only ever able to access their own repositories but not the repositories of the other users. - All this, you want to achieve using stock SSH and plain Git without resorting to using third-party software. If I am correct, the second thing to consider is that when working this way - I mean, being called via SSH, - Git does not implement any fancy access control - in the sense of maintaining its own lists of users, their roles etc. When a Git process is called in an SSH session - either automatically, because a user on a remote machine has called something like git push ssh://... or a user has logged in interactively via SSH and has invoked Git by hand - in all these cases Git merely behaves as a normal UNIX process: it works with the credentials of the invoking user, and - now is the part you're supposedly not quite familiar yet - the permissions set on the files and directories it creates obey the usual UNIX rules. This latter fact should not be considered closely. The part with the owning user and group on the newly created filesystem objects is relatively simple: the user matches that of the user's UID, and the group - the primary user's GUID. (Yes, the reality is more complicated but let's not dig deeper.) The so-called permission bits are a more subtle concept: they are set to what the process specified, and are further modulated with the so-called umask [2]. Most of the time, a process uses 0666 and 0777 as permission bits to create files and directories, respectively, and these values is what the currently active process' umask is applied to. Now, on a typical contemporary Linux-based OS, the user's umask is 0022 (run `umask` in your shell to see what's yours). This means, for instance, that when a file is created, it gets its permission bits set to 0644, and a directory gets 0755. This means the owning group and "others" (the penultimate and the last numbers, respectively) are denied write access but are still allowed read access. Basically, that's what makes your "private" repositories readable for everyone else. What you can do about this? There are many ways to make the repositories inaccessible to everyone but the owning user, but IMO the simplest one is to make user of the "--share" command-line option of the `git-init` command: when assigned a specification of permission bits, it makes Git operating on the created repository use these bits when creating files (when creating directories, 'x' bits are added as well). Hence running something like git init --bare --share=0600 name.git will create a bare repository named "name.git" to which only the owning user (who called this command) has full access, and the other two categories of users will have no access at all. References: 1. https://gitolite.com 2. https://en.wikipedia.org/wiki/Umask -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20230724191825.tgp5zembuu6m236q%40carbon.