Jonathan Nieder [off-list ref] writes:
Junio C Hamano wrote:
quoted
Jonathan Nieder [off-list ref] writes:
quoted
Junio C Hamano wrote:
quoted
quoted
quoted
Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
Hmph, if that is the case, wouldn't it be a better direction to give
a better help for majority of the case where git-shell is used as
the login shell to allow push and fetch but not for interactive
access at all?
The first step in that direction may be to give a better canned
message, followed by a mechanism (perhaps a hook) that lets a
message customized for the site's needs, no?
The trouble is that I can't imagine a canned message that everyone
will like. (For example, I quite dislike the current one.) That's
exactly the situation in which some configurability is helpful.
I am not saying we should have a perfect canned message everybody
likes and not have any configurability. I however think we can aim
to come up with a message that covers 80% of site administrators who
do not care too much and just want git-shell to allow the standard
services without giving any custom command.
And for the remaining 20% of those who do not like the canned
message but still do not need any custom command, I think it is way
suboptimal to force them to create git-shell-commands directory for
47 users his host gives git-shell access to, and copy the "help"
script to all of them, only to get a customized message. It would
help them quite a lot if you just called /etc/git/shell-disabled or
some hook that generates a customized message; then there is no need
to add any git-shell-commands directory and a "help" script every
time he gets one new user, no?
For those who _do_ want to give customized commands to their users,
they can already have "help" script to give a friendly message. It
just felt silly to force sites to create the directory only to
refuse an access to the "custom commands" feature, especially when
the existence of that directory is a signal that the site may want
to give its users an acess to that feature.
Junio C Hamano wrote:
Jonathan Nieder [off-list ref] writes:
quoted
The trouble is that I can't imagine a canned message that everyone
will like. (For example, I quite dislike the current one.) That's
exactly the situation in which some configurability is helpful.
I am not saying we should have a perfect canned message everybody
likes and not have any configurability. I however think we can aim
to come up with a message that covers 80% of site administrators who
do not care too much and just want git-shell to allow the standard
services without giving any custom command.
Isn't the current message meant to be that? Just removing the "hint:"
line would be enough to leave me happy with it.
And for the remaining 20% of those who do not like the canned
message but still do not need any custom command, I think it is way
suboptimal to force them to create git-shell-commands directory for
47 users his host gives git-shell access to, and copy the "help"
script to all of them, only to get a customized message.
Isn't that a criticism of the git-shell-commands facility in general?
If it is common to have a lot of users with distinct home directories
but all with git-shell as their login shell, then the
git-shell-commands should not go in their home directory to begin
with, no?
I think sharing a home directory is fine and the normal thing to do
with such a restricted account, fwiw, so I am not the one to guess
what people who do something different would find most useful. Maybe
I am not the right person to have proposed this patch in the first
place --- I saw something that looked wrong and proposed what I
thought was a reasonable fix, but I am not actively depending on
git-shell myself, so...
*shrug*
Hope that helps,
Jonathan
On Mon, Feb 11, 2013 at 2:01 AM, Junio C Hamano [off-list ref] wrote:
And for the remaining 20% of those who do not like the canned
message but still do not need any custom command, I think it is way
suboptimal to force them to create git-shell-commands directory for
47 users his host gives git-shell access to, and copy the "help"
script to all of them, only to get a customized message. It would
help them quite a lot if you just called /etc/git/shell-disabled or
some hook that generates a customized message; then there is no need
to add any git-shell-commands directory and a "help" script every
time he gets one new user, no?
For those who _do_ want to give customized commands to their users,
they can already have "help" script to give a friendly message. It
just felt silly to force sites to create the directory only to
refuse an access to the "custom commands" feature, especially when
the existence of that directory is a signal that the site may want
to give its users an acess to that feature.
Again, would it not be more elegant and powerful to A) have the
shell-disabled message/hook/etc specified by git-config on some level,
be it /etc/gitconfig or ~/.gitconfig, and B) have Jonathan's patch
whereby ~/git-shell-commands/help returning non-zero closes the
connection? Have shell.c read for settings in the pattern:
[shell "disabled"]
message = "Hi, this is your server speaking. I've
replaced the usual message."
command = "/path/to/some/command"
If shell.disabled.command is defined, don't bother with the message.
If it is not, but shell.disabled.message is, display that. If neither
of them are, display the default message, and make that one more
friendly.
Even if that was implemented, there is still an argument for
Jonathan's patch. For example, I'm building a server where
~/git-shell-commands/help does something interesting. But sometimes,
something fails. When that something fails, I want to close the
connection for whatever reason.
So, any reason not to have both (on top of making a better default message)?
--
Ethan Reesor (Gmail)
On Mon, Feb 11, 2013 at 2:12 AM, Jonathan Nieder [off-list ref] wrote:
Isn't that a criticism of the git-shell-commands facility in general?
If it is common to have a lot of users with distinct home directories
but all with git-shell as their login shell, then the
git-shell-commands should not go in their home directory to begin
with, no?
I know nothing of the security issues, but why not have a
/etc/git-shell-commands?
--
Ethan Reesor (Gmail)