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.
