From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:08
"Shawn O. Pearce" [off-list ref] writes:
Hmm. core.sharedrepository is sometimes a bad solution.
core.sharedrepository means I need to give write access to both the
refs database and the object database to all members of the project.
Some of whom may not be able to be trusted with tools like "rm",
but who need real shell access to that system anyway. And sometimes
management won't allow users to have two accounts on the same system
(one that is fixed to git-shell, and one that has a real shell)
because the world would implode if a user was given two different
accounts for two different access purposes.
Ok, that was the motiviation I did not get from your original
message. It begins to make sense somewhat.
Another approach to do the same I can think of, without having
to add 50 new accounts for 50 users, would be to collect a ssh
key from each of these 50 users, and have 1 line per user in the
authorized_keys file of gitadmin.gitadmin user (who owns the
repository with the paranoia hook that decides the authorization
aspect of the repository). The authentication would come from
the environment="Name=value" option in the authorized_keys file.
Each of your aunt tillies can push or fetch over ssh using the
key she has in the gitadmin.gitadmin's authorized_keys file.
I suspect the "hackiness" factor from the aesthetics viewpoint
is probably about the same, but this would work with the current
code without patches, no?
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:44:08
Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
Hmm. core.sharedrepository is sometimes a bad solution.
core.sharedrepository means I need to give write access to both the
refs database and the object database to all members of the project.
Some of whom may not be able to be trusted with tools like "rm",
but who need real shell access to that system anyway. And sometimes
management won't allow users to have two accounts on the same system
(one that is fixed to git-shell, and one that has a real shell)
because the world would implode if a user was given two different
accounts for two different access purposes.
Ok, that was the motiviation I did not get from your original
message. It begins to make sense somewhat.
Another approach to do the same I can think of, without having
to add 50 new accounts for 50 users, would be to collect a ssh
key from each of these 50 users, and have 1 line per user in the
authorized_keys file of gitadmin.gitadmin user (who owns the
repository with the paranoia hook that decides the authorization
aspect of the repository). The authentication would come from
the environment="Name=value" option in the authorized_keys file.
Each of your aunt tillies can push or fetch over ssh using the
key she has in the gitadmin.gitadmin's authorized_keys file.
Yea. The downside to this is we have to maintain that
authorized_keys file. Today each user can generate their
own SSH key and upload to their own authorized_keys file.
I've had enough cases of users losing their SSH key and
needing to recreate it that I'd rather not have to manage
a 50 user long authorized_keys file.
I'm also not sure of what the performance implication is to SSH for
authentication with 50 public keys in a single file. Does it slow
down as its running a check against each key, or is there something
smarter to filter the keys? From the description of the format in
the OpenSSH manpage it doesn't look like its possible other than
to probe every key in turn for every authentication attempt.
In other words, the authorized_keys is a nice feature, but it seems
like its more useful for a remote backup job logging in as root, or a
"vacation mode" where a coworker is permitted to execute a specific
command while you are away. But maybe I'm missing something.
I suspect the "hackiness" factor from the aesthetics viewpoint
is probably about the same, but this would work with the current
code without patches, no?
Yes, it would, obviously. But it has the downside of needing to
manage a single common authorized_keys file. Which is something
I think I'd like to avoid.
It also doesn't do anything about upload-pack, as that has no hook
to perform authorization. Of course just adding some sort of ref
filtering hook to upload-pack is still a smaller patch than adding
all this UNIX socket redirection and an upload-pack hook. :)
--
Shawn.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:44:08
Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
Hmm. core.sharedrepository is sometimes a bad solution.
core.sharedrepository means I need to give write access to both the
refs database and the object database to all members of the project.
Some of whom may not be able to be trusted with tools like "rm",
but who need real shell access to that system anyway. And sometimes
management won't allow users to have two accounts on the same system
(one that is fixed to git-shell, and one that has a real shell)
because the world would implode if a user was given two different
accounts for two different access purposes.
...
Another approach to do the same I can think of, without having
to add 50 new accounts for 50 users, would be to collect a ssh
key from each of these 50 users,
Also, our network of servers and desktops is actually now managed
entirely through Active Directory. So all possible users already
have accounts on every server. Passwords are synchronized across
the entire network.
In other words, all of the management overheads associated with
user accounts has already been paid. Centralized SSH/SSL/PGP key
management is only adding an additional burden. For my day-job
anyway.
--
Shawn.
Hmm. core.sharedrepository is sometimes a bad solution.
core.sharedrepository means I need to give write access to both the
refs database and the object database to all members of the project.
Some of whom may not be able to be trusted with tools like "rm", but
who need real shell access to that system anyway. And sometimes
management won't allow users to have two accounts on the same system
(one that is fixed to git-shell, and one that has a real shell)
because the world would implode if a user was given two different
accounts for two different access purposes.
Ok, that was the motiviation I did not get from your original message.
It begins to make sense somewhat.
Another approach to do the same I can think of, without having to add
50 new accounts for 50 users, would be to collect a ssh key from each
of these 50 users, and have 1 line per user in the authorized_keys file
of gitadmin.gitadmin user (who owns the repository with the paranoia
hook that decides the authorization aspect of the repository). The
authentication would come from the environment="Name=value" option in
the authorized_keys file. Each of your aunt tillies can push or fetch
over ssh using the key she has in the gitadmin.gitadmin's
authorized_keys file.
Yea. The downside to this is we have to maintain that authorized_keys
file. Today each user can generate their own SSH key and upload to
their own authorized_keys file.
I've had enough cases of users losing their SSH key and needing to
recreate it that I'd rather not have to manage a 50 user long
authorized_keys file.
For what it's worth, if you haven't seen gitosis yet, you might want to
take a look - at least it makes managing the keys easy.
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
has a nice tutorial.
-- Asheesh.
--
He who despairs over an event is a coward, but he who holds hopes for
the human condition is a fool.
-- Albert Camus
Yea, I've looked at it before. There's a few reasons I don't
use gitosis, although it does look to be an excellent chunk of
Git automation:
* Its access controls aren't as powerful
Frankly the contrib/hooks/update-paranoid script is a lot more
powerful then gitosis is, in terms of how it controls what
branches a user can modify, and even what files they can change
on a particular branch. And yes, I really do have rulesets that
bend that hook to its limits.
* It uses the OpenSSH authorized_keys file format
I'm required to use the F-Secure SSH commerical server at
day-job, because its "more trusthworthy" than the portable OpenSSH
distribution. It uses a different syntax for the authorized keys,
but can do essentially the same restricted command concept.
* If its in git, I prefer raw repository access
gitosis yanks stuff out into normal files to access it at runtime,
e.g. its configuration file. I've had bad experiences with CVS not
properly updating its admin files when changes are made to them.
The update-paranoid hook I use actually cats the objects right
out of the admin ODB on demand, ensuring its always evaluating
the most recent version of the access rules.
* Its Python based.
I don't grok Python, and would rather not learn to. So hacking
on gitosis isn't something that I would be doing. Ditto with
all of my day-job cohorts. We use Perl, Bourne shell, and Java,
with some tiny amount of Tk thrown about (though I'd say I'm
probably the only one there that even remotely groks Tcl/Tk).
But thanks for the pointer.
Now if others corrected all of the above in gitosis (except the
last item of course, I don't expect it to be rewritten in one of
my preferred languages) I'd reconsider using it, because inventing
wheels sucks.
--
Shawn.