Neal Kreitzinger [off-list ref] writes:
On 3/8/2012 7:15 PM, Adrian Cornish wrote:
quoted
My plan is to use git to keep track of changes in /etc but when
committing I want to have the person making the change specify
themselves as author by adding the --author option on the commandline.
quoted
So I would like to stop accidental commits as root.
...
We use whoami in our pre-commit hook to see who the user is that is
doing the commit. I think you could also use GIT_COMMITTER_NAME or
linux $USER environment variables. Either way, the --author seems
like an unnecessary and unreliable way to get the username.
... If people can su to root
then $USER will not work because it will still be set to their
original user name (before they did su to root). Therefore, "whoami"
seems like your best solution.
When people want to raise a red flag against a commit made by root,
they are coming from two different schools.
One is "do not run 'git' or any development tool for that matter
while being root". It is a good discipline to follow in general to
limit what you do with escalated privilege to the minimum.
The other is "record who actually did the work, not 'root' that
people cannot later track down who it actually was". People from
this school do not mind running development tools as root.
And your advice is a good one for the former, but not very relevant
for the latter.
And I think Adrian is asking for the latter.
On 3/10/2012 3:54 PM, Junio C Hamano wrote:
Neal Kreitzinger[off-list ref] writes:
quoted
On 3/8/2012 7:15 PM, Adrian Cornish wrote:
quoted
My plan is to use git to keep track of changes in /etc but when
committing I want to have the person making the change specify
themselves as author by adding the --author option on the commandline.
So I would like to stop accidental commits as root.
...
We use whoami in our pre-commit hook to see who the user is that is
doing the commit. I think you could also use GIT_COMMITTER_NAME or
linux $USER environment variables. Either way, the --author seems
like an unnecessary and unreliable way to get the username.
... If people can su to root
then $USER will not work because it will still be set to their
original user name (before they did su to root). Therefore, "whoami"
seems like your best solution.
When people want to raise a red flag against a commit made by root,
they are coming from two different schools.
One is "do not run 'git' or any development tool for that matter
while being root". It is a good discipline to follow in general to
limit what you do with escalated privilege to the minimum.
The other is "record who actually did the work, not 'root' that
people cannot later track down who it actually was". People from
this school do not mind running development tools as root.
And your advice is a good one for the former, but not very relevant
for the latter.
And I think Adrian is asking for the latter.
Now I see. In that case, at the point pre-commit is run git has not
overriden GIT_AUTHOR_IDENT with your --author value, yet. I don't know
if that is a bug or not. The prepare-commit-msg hook is the same way.
However, by the time the commit-msg hook runs git has placed your
--author override into GIT_AUTHOR_IDENT so if you check it there it will
work and you can abort the commit. Of course, at that point the user
has already typed their commit message and may lose it. You could
create a git alias like "git root-commit" that prompts them to enter
their authorname and then runs git-commit --author with that user
provided value. Pre-commit hook could detect root user and error out
telling them to run git-root-commit instead.
v/r,
neal