Bug 781589 - gitolite - missing file causes a malfunction
Summary: gitolite - missing file causes a malfunction
Alias: None
Product: Fedora
Classification: Fedora
Component: gitolite
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-01-13 19:41 UTC by Lubos Stanek
Modified: 2012-03-06 07:06 UTC (History)
5 users (show)

Fixed In Version: gitolite-2.0.3-3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-01-24 14:53:32 UTC

Attachments (Terms of Use)

Description Lubos Stanek 2012-01-13 19:41:55 UTC
Description of problem:
The report_version() function in gitolite.pm requires a file conf/VERSION.

Version-Release number of selected component (if applicable):

How reproducible:
$ssh gitolite@<server> info

		***** ABORTING *****
        open /usr/share/gitolite/conf/VERSION failed: directory or file does not exist at /usr/lib/perl5/vendor_perl/gitolite.pm line 125

Steps to Reproduce:
1. install gitolite
2. perform steps per README-fedora
3. try to get the access information
Actual results:
		***** ABORTING *****
        open /usr/share/gitolite/conf/VERSION failed: directory or file does not exist at /usr/lib/perl5/vendor_perl/gitolite.pm line 125

Expected results:
hello reporter, this is gitolite 2.2.1-1.fc17 running on git
the gitolite config gives you the following access:
     R   W 	gitolite-admin
    @R_ @W_	testing
Connection to <server> closed.

Additional info:
The required change in the gitolite-2.0-rpm.patch was lost in the first 2.2 package release.

Also notice that the line 598 of gitoline.pm:
    print "\rthe gitolite config gives you the following access:\r\n";
is missing the "\n" control character and it overwrites the previous line in the screen output ("hello reporter, ...").
It would be great to report it upstream.

Comment 1 Gwyn Ciesla 2012-01-18 19:59:15 UTC
I'm not sure where the VERSION file should come from the Makefile seems to create and then remove it, and it's not present in the upstream tarball.

Can you point out what in the patch changed that caused this?

Comment 2 Lubos Stanek 2012-01-18 20:46:04 UTC
The patch from previous series (gitolite-2.0.3-2.fc16) contained:
diff -ur sitaramc-gitolite-4c1e4b2.orig/src/gitolite.pm sitaramc-gitolite-4c1e4b2/src/gitolite.pm
--- sitaramc-gitolite-4c1e4b2.orig/src/gitolite.pm      2011-08-08 00:17:56.000000000 -0400
+++ sitaramc-gitolite-4c1e4b2/src/gitolite.pm   2011-08-08 14:10:35.330500567 -0400
@@ -493,7 +493,7 @@
 sub report_version {
     my($user) = @_;
     print "hello $user, the gitolite version here is ";
-    print slurp( ($GL_PACKAGE_CONF || "$GL_ADMINDIR/conf") . "/VERSION" );
+    system("rpm", "-q", "--qf", '%{version}-%{release}', 'gitolite');
 sub perm_code {

You can patch current code similarly, add a VERSION file created when cloning the source tree for packaging, or generate it at the build time like:
echo "%{version}-%{release}" >conf/VERSION

Comment 3 Gwyn Ciesla 2012-01-24 14:42:34 UTC
Since we already patch to get the version from RPM, I'll just comment that out.

Comment 4 Konstantin Ryabitsev 2012-02-13 17:34:04 UTC
Hi, I would seriously suggest finding better solutions than calling rpm, if only because this completely breaks under SELinux (and is a bad practice generally).

Comment 5 Gwyn Ciesla 2012-02-13 17:51:39 UTC
I agree that calling rpm isn't ideal, but it seems to work on my selinux-enabled f16 box.  What does it do on yours?

Comment 6 Konstantin Ryabitsev 2012-02-13 18:12:17 UTC
It probably only works because gitolite user is set up as unconfined_u for you, so it never transitions to the gitosis_t domain. This is the default behaviour, but it's hardly useful, as it executes gitolite as unconfined.

Otherwise, the following is returned:

ssh gitolite@moppet expand
hello mricon, the gitolite version here is Can't exec "rpm": Permission denied at /usr/share/perl5/vendor_perl/gitolite.pm line 496.
you have access to the following repos on the server:
     R   W 	<gitolite>	gitolite-admin
    @R_ @W_	<gitolite>	testing

Comment 7 Konstantin Ryabitsev 2012-02-13 18:58:27 UTC
By the way, if you want to test:

Create a file called "mygitoliteuser.te" with the following contents:
policy_module(mygitoliteuser, 1.0.0)
role mygitoliteuser_r;
gitosis_run(mygitoliteuser_t, mygitoliteuser_r)
gen_user(mygitoliteuser_u, user, mygitoliteuser_r, s0, s0)

Then run:
make -f /usr/share/selinux/devel/Makefile mygitoliteuser.pp
semodule -i mygitoliteuser.pp
cd /etc/selinux/targeted/contexts/users
sed 's/guest_/mygitoliteuser_/g' guest_u > mygitoliteuser_u
usermod -Z mygitoliteuser_u gitolite

This should set up gitolite to run as a very restricted user with the only permission to transition to the gitosis_t domain (used by gitolite), as opposed to running unconfined.

Comment 8 J.H. 2012-02-13 23:36:16 UTC
Beyond the security considerations that Konstantin is bringing up (which are obviously pretty serious), there are 2 additional problems:

1) The "fix" wasn't discussed with the Gitolite author himself, Sitaram is actually quite responsive and if there was a bug upstream he could have fixed it and you wouldn't be maintaining a random patch.

Specifically, according to Sitaram, "the verion file gets created -- in a manual (non RPM/DEB) install -- when you run gl-system-install.".  If you are assuming this isn't getting run, then the rpm build process 

2) Constantly running this rpm command is relatively expensive on a busy server.  A text file (which is what's intended) is extremely cheap to read and output, running rpm - not nearly as cheap.  It also adds a very messed up dependency on rpm, that quite honest makes no sense.

Suggested fix:

Instead of using rpm like this (which is an issue on a number of levels) the build process should just create the appropriate file and include it in the rpm.

Comment 9 Gwyn Ciesla 2012-02-16 14:55:17 UTC
Logical.  I've fixed this in the rawhide update to 2.3.

Comment 10 Konstantin Ryabitsev 2012-02-16 19:17:02 UTC
Thanks, Jon. Could you also put the same solution in the EPEL branches?

Comment 11 Gwyn Ciesla 2012-02-17 15:27:11 UTC

Comment 12 Fedora Update System 2012-02-17 15:27:56 UTC
gitolite-2.0.3-3.el6 has been submitted as an update for Fedora EPEL 6.

Comment 13 Fedora Update System 2012-02-17 15:28:09 UTC
gitolite- has been submitted as an update for Fedora EPEL 5.

Comment 14 Konstantin Ryabitsev 2012-02-17 17:12:56 UTC
Great! Thanks for your help with this.

Comment 15 Fedora Update System 2012-03-06 07:05:21 UTC
gitolite- has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2012-03-06 07:06:07 UTC
gitolite-2.0.3-3.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.