avoiding anonymous commits from root/shared accounts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I have a question about what is probably an unusual use-case, where git is being
used from the root account, or an account shared by various committers.


I'm setting up a shared git repository, currently accessed via plain ssh to the
server in question. The code has been inherited, and is migrated from CVS.

The code is a sysadmin tool designed to set up a new server and keep its
configuration synchronised to one of several templates thereafter. Typically, it
is checked out in /root on a freshly installed server, and "make all" is run as
root to configure the services, set up user accounts, etc.

>From then on you pull updates from the repository, run "make all", and the
machine is reconfigured, services restarted, etc. as necessary.

The problem is maintenance of this code.  In the past, fixes might be made on
any server, then pushed back into the repository to be replicated everywhere.
There are several users, each of whom might commit changes to this tool.  When
it was in CVS, a common account was used to allow commits from anyone and
anywhere - and as a result nothing can be attributed to anyone.



I want to avoid these anonymous commits from now on.  The trouble is, I'm not
sure the best way to, as there is no guarantee any accounts but root will exist,
and if they do, some of these are shared accounts various people can log in as.
(This may or may not be advisable, but for now that's the way it works)

I also don't want to make it easy for the maintainers to do the right thing,
they will already be re-adjusting to git.  For that reason, just mandating that
everyone sets $GIT_AUTHOR_NAME etc. manually on log-in isn't very satisfactory.

The best idea I've come across seems to be some sort of wrapper for git, which
if no $GIT_USER_* is defined, can use $SUDO_USER and/or `who am i` to identify
the original log-in account, and sets $GIT_AUTHOR_NAME etc. - else if it can't
do this, it refuses to commit.  Or perhaps it would be a script which spawns a
shell with the right environment to invoke git commands from, after successfully
determining the identity.


But before I investigate this avenue any further, I wonder is there any prior
art addressing this sort of situation, using git?

Thanks

Nick
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]